gnumeric виснет. Судя по strace — ждёт какую-то херню от dbus (который у меня таки сэссионный в итоге запущен).
<<That said, I have to admit to being particularly disappointed with the performance argument for merging it. Having looked at the dbus performance, and come to the conclusion that the reason dbus performs abysmally badly is just pure shit user space code, I am not AT ALL impressed by the performance argument. We don't merge kernel code just because user space was written by a retarded monkey on crack. Kernel code has higher standards, and yes, that also means that it tends to perform better, but no, "user space code is shit" is not a valid reason for pushing things into the kernel.>>
from Linus Torvalds lkml.org
from Linus Torvalds lkml.org
Ещё банальность: чем меньшэ ядро, тем лучшэ. Поскольку ядро очень трудно отлажывать, и ошыбки в нём дорого обходятся. По сути, это многопоточное приложэние без какого-либо ограничения доступа.
Вот я совершэнно уверен, что вносить в ядро драйвера USB-устройств (включая USB-hdd) было ошыбкой. А уж ttyACM/ttyUSB — очень болезненной ошыбкой.
Вот если ip в ядре — это нормально, то поводу tcp... Ну, есть варианты. Хотя и тожэ можно. То есть, понятно, что он решает: для деления приложэний по портам потребовался бы либо два context switch на read(), либо эклектический ip-стэк с внутренним роутером пакетов на базе байт по смещениям.
Но вот следующий уровень тащить туда, message broker — это, извините, вообще идиотизм. Существенно большый, чем тащить в ядро web server. Поскольку web server в ядре, при сопоставимом уровне абстракцыи, хотя бы теоретически можэт сделать хоть что-то полезное — ускорить там синтэтический тэст.
kdbus делает только вредные вещи: ограничивает ipc локальным компьютэром, и более ничего.
Вот я совершэнно уверен, что вносить в ядро драйвера USB-устройств (включая USB-hdd) было ошыбкой. А уж ttyACM/ttyUSB — очень болезненной ошыбкой.
Вот если ip в ядре — это нормально, то поводу tcp... Ну, есть варианты. Хотя и тожэ можно. То есть, понятно, что он решает: для деления приложэний по портам потребовался бы либо два context switch на read(), либо эклектический ip-стэк с внутренним роутером пакетов на базе байт по смещениям.
Но вот следующий уровень тащить туда, message broker — это, извините, вообще идиотизм. Существенно большый, чем тащить в ядро web server. Поскольку web server в ядре, при сопоставимом уровне абстракцыи, хотя бы теоретически можэт сделать хоть что-то полезное — ускорить там синтэтический тэст.
kdbus делает только вредные вещи: ограничивает ipc локальным компьютэром, и более ничего.