Вышел cgroups v2

Сеть? Но лучше её убрать вообще (и лучше все семейства сокетов)

эээ. бодро. обьясниться не хочешь? имхо как раз таки domain sockets самое очевидное, годами протестированное решение озвученных юз-кейсов.

Вон извращенцы из netflix юзают «chaos monkey», которая периодически вырубает случайную ноду.

ты серьезно сейчас сравнил pid 1 и микросервис от которого в первую очередь требуется скорость разработки?

энивей, главная проблема не в reliability при таком подходе, конечно если есть механизмы восстановления, пусть себе умирает и перезапускается. проблема в security, локальные escalation of privileges никто не отменял. кроме того, рестарт это всегда ублюдочный вариант, даже на локалхосте — где гарантии что условия вызвавшие падение тут же не повторятся?

Ну перезагрузишь винлинупс, подумаешь делов то (ну и ничего, что продакшн сервер, пускай освежится). А когда systemd засрет свои юниты (а почему бы и нет?), переустановишь. Раз плюнуть! Я вот масдайку 95-ю раз в месяц переустанавливал, руки не отвалились!!11

ну про второе я писал, а первое это были ранние предложения, потом они сменились, на сделать при этом dbus хорошо (что похоже не удалось, раз не принимают?)

Сеть? Но лучше её убрать вообще (и лучше все семейства сокетов) и zero-copy нет.

zero-copy есть, а стандартный вариант для этого юзкейса это как раз-таки unix socket, в которых и zero-copy и передача пидов и хэндлов в наличии.

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

ну dbus так и работает плюс минус.

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

Pro-tip: чтобы передача Gb не вносила оверхеда - нужно никуда его не передавать. На этом основаны все быстрые варианты, например использовать shared memory (тут при наличии контроля через cgoups в v1 были приличные проблемы), или отдать хэндл файла и пусть себе читает как хочет, или положить файл в доступ (на namespaces накладывается прекрасно).

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

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

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

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

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

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

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

имхо как раз таки domain sockets самое очевидное, годами протестированное решение озвученных юз-кейсов.

Почему тогда в андроиде используется binder? Почему во всех настольных системах используется D-Bus? Давно у себя на машине запускал busctl?

ты серьезно сейчас сравнил pid 1 и микросервис от которого в первую очередь требуется скорость разработки?

Не микросервис. Chaos monkey убивает амазоновскую ноду целиком.

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

Понимаешь, линукс, ну может быть кроме Каноникала, никто не рассматривает как декстопную платформу. Как платформу для эмбеддед — да, как платформу для ЦОД/облаков — да, как платформу для IoT и прочих тосетров — пожалуйста, даже как платформу для новомодных white-box коммутаторов + SDN + OpenFlow.

Об этом ещё Кон Коливас сокрушался лет десять назад.

Во всех вышеперечисленных вариантах фирмварь либо гоняют в хвост и в гриву, либо абсолютно пофиг *что* именно сбойнуло. Сбой системного демона, и без разницы какой у него пид, будет означать сбой всей системы с последующей её перезагрузкой. Неприятно, но не катастрофа.

Паника даже предпочтительнее, т.к. можно загрузить специальное ядро, и получить узел в предопределённой конфигурации.

Эскалация осуществляется ровно так же на pid 1, как и на pid 101, и никаких особых последствий не приносит. Модульность не влияет на безопасность: крайне сложно сконфигурировать модульный системный демон чтобы он работал под разными capability (опять, вышеприведённый s6 с ними не работает, ибо не позикс), а значит поверхность атаки будет как минимум не меньше. Ещё сложнее, чтобы он мог работать в разных контекстах SELinux. В реальных условиях его будут просто отключать как это делают сейчас в RHEL/федоре.

Намного более реальным выглядит вариант со связкой LSM и cgroups. Но его на сегодняшинй момент нет, потому что нет сторонних cgroups-менеджеров, только systemd.

Короче говоря, всё совсем и совсем непросто.

Почему во всех настольных системах используется D-Bus?

Потому, что в D-Bus основная фишка это не возможность передавать гигабайты и быть быстрым (и то и другое он решает хуже других), наверное?

Во всех вышеперечисленных вариантах фирмварь либо гоняют в хвост и в гриву, либо абсолютно пофиг *что* именно сбойнуло.

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

(опять, вышеприведённый s6 с ними не работает, ибо не позикс)

если внимательно посмотреть на s6, то можно обнаружить, что с полными правами там должен работать только pid-1 - это 600 строк простого c кода, дальше можно радостно сбрасывать привелегии доступной в используемой OS способами. Конечно нету магической строки в конфиге DROP_CAPS=CAP_SYSADMIN и т.п., это да..

Но его на сегодняшинй момент нет, потому что нет сторонних cgroups-менеджеров, только systemd.

с сейчас cgoups-менеджеры и не нужны, ну и конечно же cgroup демоны вне systemd есть, правда они нафиг не нужны.

Реализовали бы сначала по-человечески, а потом бы думали

Дык, они и пытаются. Кстати, bus1 вроде бы пилят... Но там пока всего ничего...

Может быть ребята из MPI подтянутся... Им вроде бы как давно было нужно.

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

если внимательно посмотреть на s6, то можно обнаружить, что с полными правами там должен работать только pid-1

Это как раз и понятно. Теория-то красива... А вот практика... Реальность — она, сука, богатая.

Может быть и нужно сделать PID 1 виртуальной машиной, которая будет исполнять простые инструкции (запустить процесс, загрузить модуль, исполнить нетлинк-команду) при полной поддержке LSM + evm/lma + ядерные ключи + TPM + ... А всё остальное либо будет создавать для неё программы, либо рулить в рамках своих полномочий в юзер-контейнере.

Но это долгий и неочевидный НИОКР, без гарантии. Systemd же — чисто инженерный подход.

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

https://lwn.net/Articles/405346/

The first of these patches is motivated by a desire to make MPI faster. Intra-node communications in MPI are currently handled with shared memory, but that is still not fast enough for some users. Rather than copy messages through a shared segment, they would rather deliver messages directly into another process's address space.

AF_DBUS присутствует ;)

PID-1 достаточно специфический процесс, чтобы делать его виртуальной машиной, но в чем проблема так сделать? Сделать же все описанное выше на *любом* ините в т.ч. даже ужасном sysv-init в версии suse, я не вижу проблем.

Systemd же — чисто инженерный подход.

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

Я честно не понял при чем как AF_DBUS и как он поможет получить zero-copy более быстрый, чем shared-memory... Если возможность передачи страниц в адресное пространство другого процесса, то как указали, есть vmsplice, который это позволяет, что будет лучше в dbus?

хотя может это я дурак и чего-то очевидного не понимаю..

Systemd же — чисто инженерный подход.

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

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

Я честно не понял при чем как AF_DBUS и как он поможет получить zero-copy более быстрый, чем shared-memory...

AFAIK, vmsplice - это копирование из одного адресного пространства в другое, а под (нормально реализованным) AF_DBUS лежит memfd - тупо ремапинг страниц из одного адресного пространства в другое.

Systemd же — чисто инженерный подход.

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

насколько я помню в vmsplice есть вариант, передачи страницы, что-то там gift, хотя я оказывается плохо запомнил, это подарок ядру и не факт, что больше копирований не будет

SPLICE_F_GIFT The user pages are a gift to the kernel. The application may not modify this memory ever, otherwise the page
cache and on-disk data may differ. Gifting pages to the kernel means that a subsequent splice(2)
SPLICE_F_MOVE can successfully move the pages; if this flag is not specified, then a subsequent splice(2)
SPLICE_F_MOVE must copy the pages. Data must also be properly page aligned, both in memory and length.

SPLICE_F_MOVE Attempt to move pages instead of copying. This is only a hint to the kernel: pages may still be copied if
the kernel cannot move the pages from the pipe, or if the pipe buffers don't refer to full pages. The ini‐
tial implementation of this flag was buggy: therefore starting in Linux 2.6.21 it is a no-op (but is still
permitted in a splice() call); in the future, a correct implementation may be restored.

2.6.21 было давно, что там сейчас, кто знает?

остаётся вопрос, AF_DBUS это необходимый механизм для передачи страниц из одного адресного пространства в другое, и какие там ограничения вылезают?

сляпать продукт и продавить его агрессивным маркетингом

Это и есть инженерный подход. Ещё, по уму, полагается надуть финансовый пузырь: навроде пузыря железных дорог в 30-е или навроде пузыря доткомов в 90-е или навроде «сланцевого» пузыря в 2010-е в США.

хотя может это я дурак и чего-то очевидного не понимаю..

Может быть и я чего-то очевидного не понимаю. Надо разбираться...

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

И, видимо, не судьба: https://github.com/bus1/base хотя и без копирайтов Редхата.

zero-copy есть, а стандартный вариант для этого юзкейса это как раз-таки unix socket, в которых и zero-copy и передача пидов и хэндлов в наличии.

Нашёл любопытный пост на тему: https://dvdhrm.wordpress.com/2015/06/20/from-af_unix-to-kdbus/

Учитывая, что это блог автора memfd_create и file sealing, а также одного из разработчиков kdbus и bus1, то к его мнению стоит прислушаться.

пасибо, про issues with AF_UNIX полезно было, про остальное знакомо и до этого..

сляпать продукт и продавить его агрессивным маркетингом

Это и есть инженерный подход. Ещё, по уму, полагается надуть финансовый пузырь

А, так ты просто больной...

или навроде «сланцевого» пузыря в 2010-е в США

Бгг.

AF_DBUS это необходимый механизм для передачи страниц из одного адресного пространства в другое

Нет, конечно. AF - это, внезапно, address family, а нижележащий механизм передачи может быть каким угодно. Первая реализация AF_DBUS была еще до memfd.

и какие там ограничения вылезают?

Этого не понял.

Учитывая, что это блог автора memfd_create и file sealing, а также одного из разработчиков kdbus и bus1

«I am a student in Computer Science and Mathematics and in my spare time I like coding C, working on the Linux kernel or writing firmwares.

systemd, kdbus, wayland»

Лан.

Лан.

А сколько сисколлов ты лично пропихнул в ядро?

А сколько сисколлов ты лично пропихнул

Ты лучше расскажи мне, какие такие новые сисколлы нужны для memfd и kdbus.

в ядро

Я пишу ядерный код (для разных ядер) уже лет 20, так что не испытываю священного трепета перед ядерными разработчиками %)

Всё что есть — одна сплошная болтовня, навроде генерируемой тобой.

демагогией здесь занимаешься пока только ты

о, что по ссылке, — это не объективная критика, а размахивание языком и громкими словами. «Прогнозировать» что-либо тебя никто не просил.

способность к прогнозированию это неотчуждаемая особенность интеллекта

человек только что себя определил как дебила

Проблема в том, что в обладании интеллектом этот персонаж не замечен...

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

человек, который себя определил как дебила (т.к отказывает интеллекту в свойстве прогнозирования), и знать не может, что в религиях существует собственная система логики, как и собственная теория познания. Скажем в христианском богословии активно использовалась философия Аристотеля - т.е и его система логики тоже. Буддизм имеет свою систему логики, систему логики имеет индуизм...

А светская теория познания, т.е материалистическая, она просто тупо эквивалента тексту и способам манипуляции с текстом - ни в коем случае не эквивалента тексту именно идеалистическая система познания. Но от человека, который отказывает интеллекту в прогнозировании, никто и не ожидал знакомства с мат.частью - с официальной теорией познания физики (и со всем, что из этого вытекает) от Н.Бора

Таки что означает отказ от текста и эквивалентности тексту в архитектуре ОС и прочих утилит - означает отказ от базовых для культуры методов познания.

Порошок, уходи.

Порошок, уходи.

??

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

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

В общем случае, отказ от базовых для культуры методов познания (от научного познания для Запада и для материализма) в случае разработки ОС или других прог означает отказ от возможности строить работу программы в соответствии с научными представлениями, т.е по сути своей означает отказ от качественного проектирования и возможности _опытной_ проверки проектных решений и их проектных предположений

т.к научность = текст+все инструменты обработки текста, то качественность проектирования и эффективный поиск и устранение ошибок проектирования/программирования связана с максимально широким использованием текстовых интерфейсов и методов работы с текстом.

что такое использование текстового интерфейса для программирования, и почему в этом случае процесс проектирования и жизненный цикл разработки будет приводить к качественному продукту, раскрыто ещё авторами Unix и C

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

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

Таки вышел, или просто пост в жж?