[post UNIX?] [когда будет?] Универсальный интерфейс-конструктор

PowerShell же. Вместо текста - поток объектов.

> PowerShell же. Вместо текста - поток объектов.

dbus вроде, получше этого г-на

можешь мультиплексировать с помощью awk и демультиплексировать с помощью grep, просто как концепт.

jack вроде как умеет всякое с аудиопотоком

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

> PowerShell же. Вместо текста - поток объектов.

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

> А вот если бы был более гибкий способ соединения разных программ

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

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

>> PowerShell же. Вместо текста - поток объектов.

dbus вроде, получше этого г-на

DBus - это не шелл, и даже попыток сделать шелл на его основе я не знаю.

> Допустим, я не вижу причин использовать отдельные процессы, когда всё может быть более эффективно реализовано динамически подгружаемыми модулями, разумеется, при условии сохранения интероперабельности.

Это технические детали, речь шла о принципиально новом интерфейсе, сочетающем всё хорошее от текстового и графического. А плагины для программ обычно подходят только для этих конкретных программ.

> Пример с мультимедиа хреновый, ибо перемотка.
А это предусмотрено, key-hook может одновременно управлять и аудио и видео потоками

Так ведь поточная обработка, а не шелл — unixway, как я его понимаю.

То есть костыли. Протекающие абстракции и всё-такое? Не надо из поточной обработки делать прокрустово ложе для неподходящих задач. Результат удручает.

> Так ведь поточная обработка, а не шелл — unixway, как я его понимаю.

Unixway - это простое в использовании средство конструирования конвейеров. Поточная обработка была гораздо раньше.

> То есть костыли. Протекающие абстракции и всё-такое? Не надо из поточной обработки делать прокрустово ложе для неподходящих задач. Результат удручает.

Ну в видео-плеерах же как-то работает и аудио с видео синхронизировано...

Ну в видео-плеерах же как-то работает и аудио с видео синхронизировано...

Где ты видел плеер, который форкает двух чайлдов, для проигрывания видео и звука?

Потому и работает, что всё в одном блобе находится.

Программа может открыть любое число потоков чтения и записи с указанием типа и краткого описания (stdin, stdout, stderr, xmlin и xmlout какие-нибудь). Пайп создаётся либо автоматически при совпадении типов (и описания, тут можно придумать систему приоритетов, чтобы тот же xml сначала пихать в xmlin, если такого нет, то в stdin), либо процессы сами решают, какой пайп выдать наружу для такой-то задачи, либо потоки принудительно задаются средствами шелла.

Традиционное и уже существующее такое не сломает.

xmlin и xmlout какие-нибудь

Подумай над тем, почему пользы от них никакой (абсолютно никакой) не будет.

Все это круто, конечно. Однако, компании, делающие софт для пользователей, хотят охватить как можно большую аудиторию и выпускают говнецо, малофункциональное, неповоротливое, зато простое в обращении.(как правило) И те, которые пишут под Linux тоже. Наверно, в условиях рынка это и правильно.
А идеи правильные, ИМХО.

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

1) Спецификации для потоков данных.
2) Передача данных по ссылке.
3) Софт построен вокруг обработчиков потоков данных.
------------------
ИМХО, ничего нового не будет, пока не появится ОС на замену Unix-like систем. Например, пункт 2) влечет за собой:
1) Надо бы нехилую систему для управления доступом к данным.(или к памяти?) (первое, вроде, более высокоуровнево(как пишется это слово?0_о) звучит)
2) А как она будет коагулировать с процессами? Может тогда пусть ОС будет предоставлять виртуальную машину довольно высоко уровня, а процессы будут иметь одно адресное пространство на всех?
------------------
4) Софт пускается в высокоуровневой виртуальной машине, ориентированной на то, чтобы программы использовали компоненты друг-дуга, перекидывались данными.(что-то вроде лиспа? ;)) Например:
1) Листинги программ состоят из достаточно декларативных определений алгоритмов.
2) Программы загружаются в общую кучу.
3) Можно запустить программу-демон, которая начнет тягать алгоритмы и данный из общей кучи.
Подразумевается, что ВМ сама должна разруливать политики безопасности, доступ к данным, блокировки всякие и т.д.
==============================
Наверное, написал кучу бреда. Пойду дальше писать на ``замечательном" ``высокоуровневом" языке с++.

Это первое, что пришло мне в голову.

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

>Ограниченное число стандартных потоков. Только stdin, stdout и stderr и всё.
на то они и стандартные. Никто не мешает открывать больше

по крайней мере, я не нашел оператора, что бы перенаправить только stderr.

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

Потоки по традиции завязаны на plain-text

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

Советую еще раз ознакомиться с матчастью перед вбросом

>facepalm.sh. Человек, не осиливший даже такие банальные вещи в мане найти, пытается о чем-то рассуждать

Он имеет в виду именно пайп через |. То есть он имеет в виду, что никак не получится без использования именованных пайпов перенаправить 1 поток в одну программу, а 2 в другую.

> Универсальный интерфейс-конструктор. когда будет?

Никогда. Почитай ЛОР — все ссут кипятком при выходе очередного костыля и высирают кирпичи, когда предлагается что-нибудь действительно улучшить, сделать логичнее, устранить лишние сущности.

Интерфейс-конструктор будет не понятен ни быдлоюзерам, ни быдоадминам, ни быдлопрограммистам.

95%. Ибо.

А, да: тред не читал.

Plan9 и Libmo - всё уже сделано.

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

не знаю, что он имел ввиду, астралом не владею :) Вычленить только stderr в конвеере не сложно.

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

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

А что, за использование именованных пайпов по рукам бьют?

> Зачем одно адресное пространство? Это же такое решето, что дальше уже некуда.
Как раз наоборот. Если софт работает в годной ВМ, то можно делать очень гибкие политики безопасности. А еще не тратится время на переключение контекста.

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

Ээээ... Щито? Политики безопасности - это одно, а разделение адресного пространства - совершенно другое.

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

Если ты про одно адресное пространство, то проблем быть не должно: памятью должна управлять ВМ.

man ffmpeg

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

Ты не забыл, что у программ есть обычно ключи, вроде: --afile=AUDIO_FILE, --vfile=VIDEO_FILE ? Все программы завязанные на обработке файлов работают с файлами, а не с потоками. Еще скажи, что ты не можешь «выдрать» звуковую дорожку из контенеров (например, avi) и положить ее в отдельный файл.

>Вычленить только stderr в конвеере не сложно.

Как? '|&' — это шорткат для '2>&1 |', поэтому stderr и stdout всё равно будут направлены в одно место.

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

хотя вру, таки можно и без именованных. man coproc

Элементарно

bar 2>&1 1>/dev/blackjack | hookers

>PowerShell же. Вместо текста - поток объектов.

не упоминай всуе эту пародию на шелл, придуманную тяжело больными ООП головного мозга индусами

Plan_9 же! Оно готово, можешь использовать.

Элементарно

Но где здесь вторая команда?

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

P.S. Чего это тебя попёрло? :)

> ключи, вроде: --afile=AUDIO_FILE, --vfile=VIDEO_FILE

Это не так интересно, как синтаксис VLC.

Кстати, кто может подсказать, VLC научили понимать внешние фильтры? Вроде несколько лет назад значилось в планах.

>Но где здесь вторая команда?

hookers, не?

>самый главный недостаток конвейеров: отсутствие обратной связи.

для чего оно тебе нужно? Пример приведи

>для чего оно тебе нужно? Пример приведи

Например, так любимая всеми идея Истинно Юниксвейного Браузера:

curl | render | less (хотя тут нужно что-то посерьёзней)

Связь render → curl очевидна: помимо html нужно будет подгрузить картинки, *.css, *.js, фреймы… У less тоже должна быть связь с curl (те же реакции на жабоскриптовый события).

Короче, из чистого *конвеера* ничего сложнее w3m (и тот без картинок) не сварганишь.

Не, которая обрабатывает stderr.

Да, что-то я не подумал, что от порядка зависит...

>Скажем, есть программы (в скобках условные названия):

...

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

>Например, так любимая всеми идея Истинно Юниксвейного Браузера:

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

В целом, это реализуемо, но смысла нет. Скорее, proof of concept, чем удобное решение.

>Не, которая обрабатывает stderr.

на stdin hookers придет как раз чистый stderr от bar

>Ограниченное число стандартных потоков

А какие ещё ты можешь придумать _стандартные_(т.е. присущие всем программам) потоки?

В пайп можно перенаправлять только stdout

См. п.1 - «стандартно» ошибки не могут быть адекватно обработаны программами. пока.

Потоки по традиции завязаны на plain-text

Это не традиция. Можешь представить ввод шаблона поиска для гипотетического grep-а по видеопотоку? Я пока нет.

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

man bash: /coproc, /Process Substitution, ну и упомянутые уже фифо. Простота '|' недостижима - для этого у команды должно быть более 2х «концов», со всеми вытекающими и втекающими в уникальных направлениях каналами.

Тьфу, елки, эти башевские редиректы. Хорошо, где команда обрабатывающая stdin bar?

2) В пайп можно перенаправлять только stdout, хотя ещё есть |& который перенаправляет и stdout и stderr, но в bash, по крайней мере, я не нашел оператора, что бы перенаправить только stderr.

Глупый, что ли?

$ (echo 'stderr' > /dev/stderr; echo 'stdout' > /dev/stdout;)
stderr
stdout
$ (echo 'stderr' > /dev/stderr; echo 'stdout' > /dev/stdout;) 2> /dev/null
stdout
$ (echo 'stderr' > /dev/stderr; echo 'stdout' > /dev/stdout;) 1> /dev/null
stderr
$ (echo 'stderr' > /dev/stderr; echo 'stdout' > /dev/stdout;) 1> /dev/null 2> /dev/null
$

Или ты что-то не то имел ввиду?

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

Сокеты спасут. Пайпы в подобной задаче абсолютно бессмыслены.

>Хорошо, где команда обрабатывающая stdin bar?

судя по прогрессирующему тупняку, следующий вопрос будет «что такое баш»

на кой ляд сокеты разводить на локалхосте?