Спросить-то чё хотел?

ниче.

все никак не научусь (на|в)брасывать

дьявольщина
подрывная деятельность сионистов-извращенцев в ядре продолжается

Отставить панику. Вот Hurd вчера обновился до 0.6...

Попробуй не вбрасывать.

Грег за друзиков из RH обиделся?

офтопъ

качественный и холиварный вброс это один из пунктов ЛОРовского чеклиста для каждого пятизвездочного^W пользователя

добавлю ка я

From One Thousand Gnomes <> Subject Re: [GIT PULL] kdbus for 4.1-rc1

Look, us kernel developers only work on one huge, multithreaded, global
state binary. Our experience in multi-application interactions with
shared state and permission requirements is usually quite limited. If
you don't trust the developers of those programs outside the kernel,
don't use them, there are still distros out there that don't require
them.

Speak for yourself. There are a lot of us here who work and have worked on low level messaging, on networking, on clusters and on things like distributed shared memory, infiniband etc. I've worked on networks, including broken stateful protocols, I've maintined and developed internet and ISDN router code, I've worked with message passing realtime systems.

Equally the folks who wrote dbus generally also know sweet fa about writing a kernel and maintaining it for 25 years. Gtk is on its 3rd completely incompatible instance (and has incompatibilities even within major versions), Gnome is on its third major incompatible release - closer would be to say at least the «second project with the same name», and neither are as old as the kernel.

dbus is not an appropriate design for a kernel messaging layer for a variety of reasons. That's not to say dbus shouldn't be able to use a fast kernel messaging layer, or that one shouldn't exist.

dbus is basically a very large very specialized and somewhat flawed policy engine on top of what should be simple messaging. The two need splitting apart.

Abstract low level messaging layers are not a new concept. V7 unix had one experimentally. It's about getting the separation right.

IMHO that probably involves getting the right people in the right place together - dbus designers, MPI and realtime people, kernel folks and possibly also some of the hardware messaging folk.

In filesystem terms

- stop writing a dbus only file system - figure out what a messaging «vfs» looks like - figure out what an clean low level kernel model looks like - figure out what has to be where to put the policy in userspace

What might also be worth review is how much dbus traffic actually ought to be an object store implemented say with tmpfs and inotify type functionality (or extensions of that) so that you can set/read/enumerate/get change notifications on properties.

Alan

Да, там каждый раз такое случается. Приходит Грег, постит свой шлак. Через пару недель в тред забредает Энди и говорит «Чуваки, тут дыра, тут дыра и тут дыра в дизайне. Зачем это вообще нужно?». Вылезает Грег и начинает орать, что это быстро, модно и молодежно. Приходит Эрик и поддерживает Энди. Грег начинает истерить, что его никто не любит. Приходит Виро и говорит, что там ещё больше дыр, чем думал Энди и вообще выглядит как эталонное ненужно. Потом Грег правит минорные проблемы и итерация повторяется.

спс за краткий пересказ последних Х серий (серьезно).

Я почитал дискусию 2х итераций и мне показалось что Грег заинтересован в качественной реализации..

То ли Энди, то ли ещё кто-то писал хороший пост о том, что попытка засунуть kdbus выглядит как DOS. Чуваки постят код, правят минорные баги, постят код, правят минорные баги... Пока обсуждающим не надоест каждый раз говорить одно и то же и они не махнут рукой. Но в этот раз все уперлись и пошли на принцип.

кратко и понятно, спс

По ссылке ЛОР-эффект

Там главный спор не о реализации как таковой, а о том, нужен ли dbus в ядре в полном виде, мол, протокол изначально не идеальный, и почему бы не сделать как надо сразу, а не копировать костыли из юзерспейса. Грег заявляет, что в этом плане всё ок - костыли он поправил, а остальную часть протокола менять нельзя, так как иначе не работает. Ему же говорят, что таки нет.

И очень много всякой херни не по теме, у Грега идеальное терпение, был бы это Линус - весь lkml бы матом покрылся.

Грег об этом каждый раз заявляется. А потом кто-нибудь в очередной раз тыкает Грега носом в метаданные к каждому пакету и связанные с этим проблемы безопасности.

Капитан Джек Воробей

Отставить панику. Вот Hurd вчера обновился до 0.6...

Hurd который Debian GNU/Hurd?

Не уверен обновили ли уже Дебиан, но скоро должны...

Многохурдие

Не уверен обновили ли уже Дебиан, но скоро должны...

Погодите, их много что ли? Есть какой-то GNU/Hurd который не Debian? Arch, насколько я знаю, уже мёртв. Guix ещё не грузится (сегодня письмо от Phant0mas'а получил, к концу лета рассчитывает, что будет грузится).

Интересно, когда поттеринг пропихнет wayland в ядро?

Hurd это ядро.
GNU это «обязка». Утилиты, скрипты и прочая дребедень.
Debian это дистрибутив.

Debian GNU/Hurd — Дебиан дистр на базе Hurd.

Для аналогии:

Linux это ядро.
GNU это «обязка». Утилиты, скрипты и прочая дребедень.
Debian это дистрибутив.

Debian GNU/Linux — Дебиан дистр на базе линукса.

0.6 чего?

Ну и у кого из них вышла версия 0.6?

Ядра. Hurd.
http://permalink.gmane.org/gmane.org.fsf.announce/2304

GNU HURD != GNU/HURD

Hurd это ядро.

Всё ещё запутаннее. Ядро — GNU HURD, операционка — GNU/HURD.

Похоже версия 0.6 относится именно к ядру, которое GNU HURD.

Разобрался

Спасибо, разобрался.

We need to go deeper

У них там в операционке GNU/Hurd с ядром GNU Hurd ещё есть микроядро GNU Mach, которое тоже недавно обновилось.

фак! после этого я начинаю думать что Леня заразил Грега

https://lkml.org/lkml/2015/4/14/434

Слава богам у нас есть Энди (и Линус на крайняк)

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

Не угадал. Ядро GNU Mach. GNU HURD это набор сервисов вокруг ядра. HURD (гну через слеш не пишется, так как хурд и так часть гну) это система.

как ты угадал?!!

I don't understand. You can not like the D-Bus model (and accordingly
the X11 model),

I thought that the general hatred level of the X11 «model» and the protocol lead to al the efforts to reimplement this properly ... in userspace (for example Wayland, right?).

I don't think anyone was ever seriously suggesting «X11 model is broken, so let's push it to kernel» ... ?

как ты угадал?!!

Ну если бы я сидел на мете, меня бы такие же мысли посещали.

Кто тут неЪ, скажите - kdus снова прокатят?

Пока похоже на то, основные ревьюеры кода отказываются дать ему зелёный свет.

да там дальше по тексту настоящая схватка

в основном припоминают предыдущие заслуги системдевщиков на ниве ломания ведра своими костылями.

дальше не читал.

Там много кого есть. Al Viro, Гномы, Biederman.

Судя по аргументации Грега - да:

Yes, it's an unfortunate design, but one that we are all stuck with

Энди в ответ:

I agree. You've sent a pull request for an unfortunate design. I don't think that unfortunate design belongs in the kernel. If it says in userspace, then user programmers could potentially fix it some day.

Пока похоже на то, основные ревьюеры кода отказываются дать ему зелёный свет.

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

Да, Грег жжот напалмом. Любопытно то, что он до сих пор (уже полгода где-то) не может привести пример того, где скорость kdbus (с которой тоже не все гладко) была бы полезна IRL.

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

Too fat.

Так всем известно, что сладкая парочка Кей+Леннарт - криворукие долбодятлы.

Грег тоже упоролся, да. Вот тот же гугль свой binder сделал и ничего - живы-здоровы.

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

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

Воот! А когда я говорил, что и в третий раз Грега и Ко завернут с kdbus'ом, мне говорили что это все ГКей Сиверс его тащил.

Да, я уже читаю с попкорном. TL;DR: Пока kdbus не готов еще, большой оверхед, многое сделано странно.

Скорее всего, не готов(tm)

TL;DR: Пока kdbus не готов еще, большой оверхед, многое сделано странно.

Хм. Вообще-то прямо сказано «всё это говно в ядре не нужно, а нужна быстрая система локального IPC, над которым можно построить и D-Bus, и MPI, и QNX».

Так Сиверса же вроде Линус прямо послал и запретил код от него принимать, не?

в следующий раз тащи с переводом

Что переводится как «не готов», в том числе архитектурно. В ядро это дело рано или поздно в каком-то виде пропихнут, но уж точно не сегодня.

Да нет, вряд-ли. Его туда уже года три пропихнуть не могут.

Что переводится как «не готов»

"- Купи слона!
- Слон не готов архитектурно. Мне нужен конь"