А что там с 9P?

Почему авторы новых проектов не пользуются им?

Часто они даже не знают о таких вещах, я полагаю.
Кроме того, неймспейсы и 9P всё-таки не родные фичи линукса.

потому что линукс это линукс, у него нет на уровне ОС и основных библиотек поддержки фич которыми plan9 обладает из коробки. Вот и развивается линух по-своему.

линукс это линукс, у него нет на уровне ОС и основных библиотек поддержки фич которыми plan9 обладает из коробки

Вопрос именно в том, почему эти фичи не встраивают в ОС.

почему эти фичи не встраивают в ОС.

потому что те кто хотят этого не в состоянии реализовать, а те кто по скиллам такое тянет не может по другим причинам. Я бы сам не стал связывать с Линусом, Дриппером итп. Плюс объём переделок колоссальный, проще создать программную платформу для этого. Так собстно и делают (message bus + framework).

Кроме того, неймспейсы и 9P всё-таки не родные фичи линукса.

/proc тоже не родная фича.

Кое-что уже сделано (ядро имеет определённую поддрежку 9P, да-да), но перестраивать всё окружение таки накладно.
Кроме того, 9P это не GNU/POSIX СОВМЕСТИМО.

Сервера 9P есть, монтировать 9P тоже умеет.

Весь ввод-вывод без ioctl, а только open, read/write, close.

Соответственно, вполне возможно сделать, например, аудиосервер с помощью виртуальной 9fs, а клиент будет монтировать ее у себя и писать в файл.

Кроме того, 9P это не GNU/POSIX СОВМЕСТИМО.

Так это и не требуется. Требуется возможность создать 9Pfs сервер, смонтировать 9Pfs, писать, читать в файлы. Все это есть в linux. Что до других ОС, то там это не сложнее, чем любой другой сервер/фс.

Кое-что уже сделано

Я знаю.

9P это не GNU/POSIX СОВМЕСТИМО.

Да неужели.

ну так частично идеи 9p в линухе воплощены, только не так всё стройно и организовано.

9p это, имхо, целая философия и подход к проектированию. Ну и меньше народа над ней работали - меньше разброда и шатания.

А в линухе какой-нить старый маразматик скажет тебе что ты мастурбирующая обезьянка (пруфы в гугле) и поэтому патч отклонён. Т.е. мейнтейнер может пойти на принцип и не принять изменение потому что оно не укладывается в его картину мира которая была составлена дцать лет назад. Меняться мало кто любит. Да и вдруг чсв пострадает...

Ещё линукс не умеет объединения точек монтирования без специальной ФС, и последнее: насколько эффективно работает 9P в линуксе по сравнению, скажем, с fuse?

Ещё линукс не умеет объединения точек монтирования без специальной ФС

Для описанной задачи этого и не требуется.

И файловые неймспейсы не требуются?

Смонтировать 9p в линуксе можно и без неймспейсов.

Экспортировать же можно вообще как угодно

Отсутствие неймспейсов сводит на нет большую часть преимуществ 9P.

Сводит. Но и остается немало.

Потому что такую махину как Linux (не только ядро, но и окружение) хрен развернешь в нужном направлении. Нельзя вот так сходу сменить дизайн с древнего Unix'а на Plan 9. Все эти революционные технологии на самом деле полностью опираются на существующие решения: PulseAudio использует ALSA, Wayland использует существующие драйвера, DRI и прочие подсистемы ядра. Даже если найти людей, которые согласятся прилепить технологии Plan 9 к линуксу, это будет выглядеть как присобачивание пятого колеса под левой дверью к «Запорожцу».
Опять же, грубым счетом тот же пульс тестировали года 3-4. Сколько будут тестировать «прилепленные» технологии - неизвестно.

печаль какая все вышесказанное, зато мне кто-то рассказывал, что в мертвых BSD с 9p и прочими плюшками таки все хорошо.

BSD
9p

Нет, нехорошо.

вэйланд решает проблему, например, нескольких видюх в одном компе. умеет это твой 9п?

умеет это твой 9п?

Не знаю умеет ли, но речь совсем не об этом. Если бы 9p всё умел то мы бы на нём сейчас сидели.

9P суть IPC между приложением и файловым сервисом.
Так что правильный вопрос — «умеет ли rio/vgadb в Plan 9 это?».

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

что такое ра

PulseAudio скорее всего.

Так что правильный вопрос — «умеет ли rio/vgadb в Plan 9 это?».

Не совсем. Мне представляется правильный вопрос: можно ли сделать единый фреймворк аудио-видео информации, передающий ее по 9P и, в конце, выводящий на монитор и аудиокарту, без существенного изменения драйвера непосредственно видеокарты и звуковушки?

кстати, я нубас

А звезду то уже получил.

как-то в голову не пришло совсем

обильный флуд и никакого мошенничества

Кстати, это можно было бы сделать используя за основу gstreamer, например.

Для этого надо

а) сделать для него вывод непосредственно в видеокарту и аудиокарту. При этом, наверное, вполне можно использовать существующие low-level драйвера, отвечающие за непосредственно вывод.

б) сервер-клиент для работы с 9P.

в) к аудио и видеоинформации добавить текстовую информацию.

Тогда графическая система будет выглядеть как сеть модулей, обменивающаяся информацией по 9P.

При этом:

а) полностью решена проблема сетевой прозрачности

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

в) и звук и видео используют одну и ту же систему

г) безопасностью занимается 9P.

И да, куча плееров становится ненужной!

cat file.mp3 > /dev/multimedia_input

и все работает.

И да, куча плееров становится ненужной!

Даже файловый сервер не должен быть комбайном.
% mp3dec < file.mp3 > /dev/audio
---
http://doc.cat-v.org/bell_labs/concurrent_window_system/
В принципе, тут многое.

Даже файловый сервер не должен быть комбайном.
% mp3dec < file.mp3 > /dev/audio

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

Как, например, plasma.

cat file.mp3 > /dev/multimedia_input

mplayer file.mp3 сделает то же самое.

куча плееров становится ненужной!

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

кстати, как будешь управлять перемоткой? Дай угадаю... «dd offset=xxx»?

mplayer file.mp3 сделает то же самое.

и по сети? и видео для file.avi? И без проблем с безопасностью?

Можно сделать так:

echo 1 > /dev/mminput/create

cat file > /dev/mminput/#ввода/input

echo pos > /dev/mminput/#ввода/offset

там уже нормальный wm есть?

и по сети?

угу, pulse audio же :)

и видео для file.avi?

да, иксы же :)

И без проблем с безопасностью?

а вот хрен :(

Короче, какие-то зачатки плана в линухе есть :)

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

9P? Для звука? Для графики? Будет жутким тормозом же.

куча плееров становится ненужной!

где-то я такое уже читал. а, да - «кукуруза - это всё!»

dd offset? что это? ты имел в виду seek?

http://habrahabr.ru/search/?q=[inferno]&target_type=posts

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

И мы изобрели XFS.

Спасибо, уже проходили.

Всё-таки современный подход «вся отрисовка на стороне клиента» глубоко правилен. Проблема в том, что для единообразного отображения всех приложений нужен если не единый тулкит, то хотя бы единый theme engine (как в Винде: WPF и Qt отрисовывают свои виджеты сами, но с использованием API системных тем). А его нет.

9P? Для звука?

Не вижу никаких проблем честно говоря.
---

там уже нормальный wm есть?

Ты про Plan 9? Ну он ещё только собирается.

9п раскрывает себя, когда каждый процесс обладает собственным пространством имён файловой системы как плане 9.