LINUX.ORG.RU
ФорумTalks

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


0

1

Чисто текстовые интерфейсы, построенные на основе принципов UNIX известны уже давно и до сих пор являются самыми удобными из существующих в активном использовании на настоящий момент.

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

Однако, классические интерфейсы UNIX неидеальны по нескольким причинам:

1) Ограниченное число стандартных потоков. Только stdin, stdout и stderr и всё.

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

3) Потоки по традиции завязаны на plain-text, хотя сейчас компьютеры часто обрабатывают аудио, видео и прочие данные. Хотя эти данные можно передавать по одному пайпу, однако см. (1) и (2)

А ведь у программы может быть больше потоков ввода и вывода, чем один.
Скажем, есть программы (в скобках условные названия):
* парсер файлов-контейнеров, который расщепляет файл типа ogg на видео-поток, аудио-поток, поток субтитров, поток тегов (media-split);
* программа, которая декодирует аудио-поток (vorbis-decode),
* программа, которая декодирует видео-поток (theora-decode),
* программа, которая трансформирует субтитры в видео-поток (sub-player),
* программа, которая накладывает несколько видео-потоков, используя полупрозрачность (video-mixer),
* программа, которая выводит видеопоток на дисплей (video-display)
* программа, отображающая текст (text-display)
* программа, ловящая нажатия клавиатуры и преобразующая их в команды для управления другими программам (key-hook)
* и наконец, программы для наложения всяких аудио и видео эффектов (audio-effect)

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

Кроме того, не смотря на удобство концепции юникс, она всё-таки удобна не для всего. Графический интерфейс используется даже самыми отъявленными консольщиками...

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

★★★★★

Последнее исправление: Xenius (всего исправлений: 1)

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

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

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

dimon555 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

Xenius ★★★★★
() автор топика

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

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

wxw ★★★★★
()
Ответ на: комментарий от unanimous

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от wxw

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

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

Xenius ★★★★★
() автор топика
Ответ на: комментарий от baverman

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

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

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

baverman ★★★
()
Ответ на: комментарий от unanimous

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от baverman

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

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

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

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

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

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

baverman ★★★
()

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

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

PolarFox ★★★★★
()

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

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

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

kermzyxer
()
Ответ на: комментарий от kermzyxer

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

Tark ★★
()

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

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

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

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

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

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

nu11 ★★★★★
()
Ответ на: комментарий от nu11

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

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

Yareg ★★★
()

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

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

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

95%. Ибо.

geekless ★★
()
Ответ на: комментарий от Yareg

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

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

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

nu11 ★★★★★
()
Ответ на: комментарий от Yareg

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

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

baverman ★★★
()
Ответ на: комментарий от Tark

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

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

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

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

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

kermzyxer
()

man ffmpeg

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

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

gh0stwizard ★★★★★
()
Ответ на: комментарий от nu11

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

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

Yareg ★★★
()
Ответ на: комментарий от Yareg

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

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

nu11 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

nu11 ★★★★★
()

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

Ygor ★★★★★
()

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

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

AX ★★★★★
()
Ответ на: комментарий от gh0stwizard

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

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

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

wxw ★★★★★
()
Ответ на: комментарий от AX

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

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

nu11 ★★★★★
()
Ответ на: комментарий от nu11

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

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

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

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

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

AX ★★★★★
()
Ответ на: комментарий от nu11

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

Yareg ★★★
()

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

...


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

ls-h ★★★★★
()
Ответ на: комментарий от AX

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

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

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

nu11 ★★★★★
()

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

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

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

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

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

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

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

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

DonkeyHot ★★★★★
()

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
$

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

ChALkeR ★★★★★
()
Ответ на: комментарий от nu11

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

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

geekless ★★
()
Ответ на: комментарий от baverman

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

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

nu11 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.