Хм… Раньше в X’ах был DPS?

Чего там только не было. Раньше иксы были полноценной операционной системой:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=c9468177486833d521ec62c7b0266b4be8200de7

Вместо того чтобы взять и сделать нормально, от иксов начали откусывать и выбрасывать куски, оставив только хреново работающий сервер окошек.

Интересно, почему не взлетело?

Оно проприетарное и запатентованное по уши Adobe. От DPS в пользу PDF отказался сам Apple, так как напугался всяких лицензионных отчислений и ограничений.

Кстати, ещё интересно, почему не стал популярным OPENSTEP (GnuSTEP)? Могла бы быть практически macOS на ядре Linux.

OpenStep по сути взлетел, он был переходным звеном между NeXTSTEP => OS X, имелись его порты на Solaris и Windows NT. OpenStep насколько я помню, был закрытый/проприетарный. Тогда слово Open не означало открытый код. А вот GNUstep что-то с самого начала приуныл. Возможно потому что было уже поздно.

поверх libXt.

Поверх Motif. Видимо что-то вроде древнего GLUT для этого PHIGS.

Хм… Раньше в X’ах был DPS? Не знал.

Да. В Solaris (только Xsun, в современном Xorg этого нет, даже на Solaris) это позволяло отправить поток в формате PostScript с клиента на сервер, и сервер «рисовал» изображение своими средствами. Утилита для просмотра PostScript в CDE, sdtimage, так и работала (почему, собственно, и «сломалась» в Solaris 10). Изначально это идея Стива Джобса, ещё когда он производил рабочие станции NeXTSTEP и продавал лицензии на OpenStep. Только в NeXTSTEP вся эта прелесть была без сетевой прозрачности.

Поскольку язык PostScript явряется Тьюринг-полным, и с его помощью можно не только «рисовать», это открывало перед пользователем широкие возможности (с т. з. безопасности).

В XFree86 тоже было аналогичное расширение (бог мой, было даже клиентское API для Motif и GTK+), но из какого-то из релизов оно было выкинуто на мороз за ненадобностью, и после форка в X.org уже не попало. Хотя, теоретически, можно собрать до сих пор. Больше подробностей здесь.

Наверное я нагуглил версию, которая использует Xt* функции.

Есть fb

Который в современном мире не использует никто кроме sahhariktu.

есть directfb

Который полностью умер, а на его официальном сайте программистам рассказывают как подготовиться к первому сексу в жизни: http://www.directfb.org/how-to-prepare-for-the-first-sex/

есть X

Который так и не довели до ума и бросили.

есть wayland

Который до сих пор сырой.

Так что всё есть как есть, то есть многообразно и это хорошо

10 стандартов и все недоделаны. Многообразие не всегда хорошо.

И давно он там развивает?

У ядра Linux и у Git в начале и в середине разработки была жёсткая рука «благосклонного диктатора», которая задавала направление. Поэтому эти проекты и стали успешными. В графике такого никогда не было.

Спасибо.

Забавно, что в составе PHIGS есть библиотека libvk с префиксом функций Vk*, который используется для современного графического API – Vulkan. Интересно, есть ли связь…

Мне почему-то вспоминается ViewKit, SGI-шное API для работы с Motif из C++:

ViewKit is a C++ application framework for UNIX. It provides a generic application, supporting components for Help, ToolTalk, UNIX process control, and more. Based on MotifApp, it incorporates Doug Young’s industry-standard method of using Motif from C++.

Список классов есть, напр., здесь. Не оно?

Когда ж вы читать научитесь?

«программа должна выполнять одну функцию и выполнять её хорошо»

Там ещё было про взаимодействие, его средства и методы. Ведь «одна функция», пусть и очень хорошая, сама по себе нафик никому не нужна. Отсюда awk, шеллы, а потом и питоноперлы.

Не в этом ли причина существования UNIX-way

Причина появления UNIX-way ровно одна: для новой области инженерных знаний потребовалась адаптация методик, проверенных и успешно применяемых в других областях на протяжении долгого времени. Причина существования UNIX-way сегодня так же ровно одна: «это просто работает», да чему бы там не работать?

https://github.com/n1ckfg/Phigs/blob/master/OpenPhigs/phigs/src/libvk/VkSubMenu.C#L21

Насколько я помню, Xm – это какая-либо реализация Motif: Проприетарная, OpenMotif или LessTif.

Для однострочников пойдёт.

в мире UNIX появилось такое комбайное дерьмо, как реализации X11

Херню не надо нести, тонкие клиенты были у всех, включая Microsoft. Железо было очень дорогое, особенно диски. Отсюда успех Novell NetWare.

Список классов есть, напр., здесь. Не оно?

Слушай, кажется оно и есть. Но в древнем и очень зачаточном состоянии. Наверное в репозиториях код PHIGS от SGI как раз со всем этим хламом.

P.S. В интернете валяется интересная книжечка от SGI на тему IRIS GL: http://bitsavers.informatik.uni-stuttgart.de/pdf/sgi/iris4d/007-1210-020_Graphics_Library_Programming_Guide_v2.0_May_1990.pdf, можно посмотреть отличия от первой версии OpenGL.

Linux-сообщество не захотело написать нормальный оконный сервер

Linux-сообщество не осилило написать нормальный оконный сервер. А что вообще оригинального написало Linux-сообщество? Ну кроме systemd конечно.

В интернете валяется интересная книжечка от SGI на тему IRIS GL

Спасибо, посмотрю на досуге.

Философии это всё фигня. UNIX-way это здравый смысл в рамках его применимости. Как и KISS.

Ребят, недавно unix интересоваться стала. Объясните в двух словах про unix way.

согласно UNIX-way, программа должна быть не каким-то монстрячным комбайном, в который понапихали всё что можно, а должна выполнять одну основную функцию, но делать это очень хорошо

«диктатора» не нашлось. во-первых, графика в древние времена была очень страшная, и многие вообще не понимали, нахрен она нужна. когда ты программируешь нормально в консоли и тебе первый раз показывают иксы - сразу возникает два вопроса: что это за ужас и нафиг он мне нужен? скорее всего, так и происходило. опытным программистам это было не нужно, а остальные писали, как могли. тем более, что тогда не было стандартов в самой разработке видеокарт. каждая карта была со своими графическими биос-функциями, со своими фишками. и всё это ещё и постоянно менялось. поэтому работа с графикой была зело геморным делом с ничтожным с точки зрения юзабельности выхлопом. графика развивалась где-то на втором плане, стандартов не было никаких абсолютно. потому и появились довольно монстрозные программы. собственно, сейчас графика - ничуть не более стандартизированная область и для системы это такой же гемор, как во времена extended CGA.

А что, чтобы кто-то fb использовал, надо чтобы кто-то другой использовал что ли? Я не вижу логики если честно. Взять тот же gnome-shell. При некоторых манипуляциях он может работать поверх fb. Равно как и многие приложения тоже могут. То что это не тренд не значит что что-то не работает. Просто ты про стандарт для юзера, ну так юзеров Linux и BSD не причесать под одну гребёнку, это разные люди и один стандарт не приживётся.

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

X вполне довели до ума и как бы не казалось небольшому количеству средне технически подготовленных хипстеров - он полностью устраивает как обычных юзеров, так и более подготовленных юзеров, чем хипстеры. Есть отдельные косяки, но этих косяков предостаточно и в Mac OS, на которую хипстеры зачем-то молятся. Строго говоря, если бы Linux использовался в промышленности для 3d дизайна и прочих прибоуток, то X был бы вылизан по этой части и никто бы даже не думал о всяких там родовых проблемах с буферизацией. Как бы это было сделано - красиво или нет - вообще насрать, кроме хипстеров, неспособных рожать красиво самим, это никого не волнует.

Что до вяленого, то не стандарт как раз потому, что подавляющее большинство юзеров X устраивают и они просто не понимают всей этой возни и перемен. Было в рамках x12 и плавного обновления, никто бы не заметил вообще.

И что касается успешности то какие у критерии успешности? Чтобы в Android были бы X, или что? Везде где есть графические среды на unix подобных осях есть X, даже на венде есть X, даже на мак ос есть X. Это не успех? Очень тогда странно. А то что люди работают, зарабатывают, используют для обычной жизни графические среды на X и даже не думают об этом это тоже не успех? Ей богу детский сад какой-то.

сейчас графика - ничуть не более стандартизированная область

Чего это? Если, например, говорить о 3D, то в мире Unix(like) много лет давно и прочно использовался OpenGL. Только относительно недавно появился Vulkan.

но то было немного другое

CTSS, DTSS уже в 60-е были. Не говоря уже про OS/360 с зачатками виртуализации. Unix тут не был никаким пионером.

«программа должна выполнять одну функцию и выполнять её хорошо», думаю, объяснять не требуется

Ну, почему же. Давайте докопаемся.
Что такое программа? Это один исполняемый файл, который породил один процесс с одним потоком? И что такое функция? Допустим, sort, сортирует текст по алфавиту. По идеи должен поддерживать максимальное количество языков. Ведь в разных языках могут быть разные особенности сортировки. Лигатуры, например. Кроме букв могут быть числовые последовательности, нужно понимать, как сортировать 1, 2, 2а, 10. Может быть 10 после 1? Теперь ещё эмодзи есть. Их сортировать? Они сортируемы вообще? И получается большое количество составляющих одной функции. Можно ли их вынести в библиотеки? Скажем, особые правила сортировки экзотического языка брать из отдельной библиотеки, в которой реализованы многие другие функции для работы с этим языком (орфография, пунктуация...). Это ещё Unix way? А если эти же библиотеки используются и кучей другого софта?

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

Это у тебя в деревне компьютеров не было.

Глянь сюда, это Irix он постарше тебя наверно будет.

https://external-preview.redd.it/yUIFB5K2SVNkKO-EpTW93nmMtRKVmg9wtq6Afc-39wQ.jpg?auto=webp&s=ec057ba85a2c85dc63618074e4a45b10ec4e77f8

Объясните в двух словах про unix way.

Это кучка мелких программ, которые срут друг в друга текстом.

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

Ну тетя, ты своими экспертными фантазиями меня очень веселишь.

В 1976 году компания McDonnell Douglas (Boeing) приобрела United Computing и впоследствии была образована McDonnell Douglas Automation Unigraphics Group. Первый релиз - 1978 г.

срут друг в друга текстом

Вот если бы изначально были объекты вместо текста, было бы в 100 раз лучше и не было бы проблем вроде неэкранированных пробелов.

внезапно, никого вообще не интересует проприетарщина. да ещё и для монстрозных копрораций.

Везде, где есть X, он объявлен deprecated и от него пытаются избавиться.

Fixed.

Это не успех?

Нет.

Поэтому прямо сейчас микросервисы во все поля и строго определенный текстовый (вау) протокол обмена данными между ними.
строго определенный

Ну да, конечно.... строго определенный это определенный кем? Этих «строго определенный» уже «вагон и телега».

Поэтому прямо сейчас микросервисы

Угу-угу, мы теперь запускаем сорок «микросервисов», которые между собой гоняют килобайты, для передачи из точки А в точку Б пяти полезных байт. А все почему? Только по тому что это «модно-молодежно» и нам позволяют мощности и пропускная способность каналов.

Ребят, недавно unix интересоваться стала. Объясните в двух словах про unix way.

Очень просто. Каждая программа должна выполнять то для чего она предназначена. Простой пример, в сравнении с оффтопиком. Надо мне написать программу которая будет в том числе отправлять почту, я сделаю комбайн в котором будет реализация отправки почты. Если мне надо написать 20-30 программ то в каждой будет внутри тот же самый комбайн. Или вариант KISS я для отправки почты буду использовать написанное не мной, но протестированное разработчиками, в разы лучше чем я один буду тестировать свои костыли. Т.е. не в каждой из 20-30 программ будет находиться нафиг ненужный одинаковый код (возможно забагованный), а просто вызов другой которая выполнит в разы лучше.

Вот если бы изначально были объекты вместо текста, было бы в 100 раз лучше и не было бы проблем вроде неэкранированных пробелов.

А что есть объект в вашем изложении? Бинарное представление вместо текстового? Таки и мы с вами здесь флудим по большому счету используя «бинарщину».

Вообще-то про deprecated это просто ложь, сразу видно эксперта уровня хипстер. На некоторых платформах, где X поддерживался официально он таким объявлен. Если говорить прямо, то это только Mac OS по сути. На всех остальных он не объявлен таковым, даже на fedora и ubuntu они скорее просто не включены по умолчанию. На лицо просто подмена понятий, потому как deprecated можно отметить что-то, что не должно более использоваться. Однако сделать так в сообществам free software и BSD просто нереально, поэтому нельзя рабочий проект объявить deprecated, это только в ваших хипстерских головах так. А люди продолжают использовать.

Что до успеха, то потрудитесь словарь пожалуйста почитать на предмет значения слова успех. X успели, захватили огромную нишу и долгое время единственным конкурентом по рыночной доле был только Windows. Потом пришла эра мобильных устройств и там пошли более простые дисплейные серверы, нежели десктопные. Однако и сейчас X живёт, здравствует и работает на достаточно большом количестве устройств. Приведи пример другого кросплатформенного дисплейного сервера или оконной системы, кто пришёл бы также к успеху?

Это всё звучит как маркетоидная шизофрения, а вот по конкретнее пожалуйста. Например как мощные вычислительные способности прекратили разделение сложного ПО на части? Ах да, никак. А как малое количество разработчиков влияет на способы декомпозиции приложений? Ах да, никак. Ну и тд.

Более того, мало что вообще изменилось с тех времён. Как только какая-то компания создаёт что-то достаточно крупное, она сразу начинает его дробить на мелкие слабо связанные друг с другом вещи. Иногда это отдельные программы, иногда это библиотеки иногда это что-то ещё. Попрограммируйте за деньги хотя бы лет 5 и всё в голове встанет на места. Ну или можете устроится инженером на автопроизводство, там тоже самое.

А что, такая проблема есть? А что, сложно передавать текстом объекты каким-нибудь json или списками лиспа?

Ну и конечно никто не обязывает передавать на вход текст. Так что мимо совершенно.

X успели, захватили огромную нишу

Самому не смешно? Где тут успех? Эта огромная ниша где-то ~1% от всех десктопов. На линуксовых/юниксовых серверах иксы сегодня никому не нужны и там их доля ещё меньше.

Если бы не иксы, глядишь линуксовый десктоп и побольше, чем 1% захватил. Сколько тут на ЛОРе было юзеров которые из-за извечного тиринга ушли на другие системы.

Микросервисы в 2к19 немного опровергают.

Нет, не смешно, у X было куда больше 1 процента давным давно. И это успех в прямом смысле, повторяю - в словарь за разъяснением смысла слова успех. Сейчас вот доля Windows снижается и это не говорит об не успешности windows. X пришли к успеху давным давно, когда многих современных его конкурентов не было даже в проекте. И это успех, не надо разводить детский сад с подменой понятий.

Иксы никак не мешали десктопу линукса, ему мешала отсутствие рекламы. Как всякий продукт без рекламы - он является не популярным продуктом. А там где реклама была, он занял и 50 и 70 и 90 процентов рынков. Ты думаешь там внутри самого Linux или других компонентов оси всё так красиво и только X ломают стройную картину что ли? Это опять же детский сад какой-то. Там куча и рудиментов, и одноразовых поделок и неверных инженерных решений. Точно также как у конкурентов. Внутри что Mac OS, что Windows настолько много говна, что X на их фоне можно в палату мер и весов как эталон инженерии поставить.

И самое главное, большинство юзеров не знает что такое тиринг, большинство юзеров пользовались вендой 95-98 и терпели простое зависание всей системы, а не то что этот ваш тиринг. Большинство юзеров терпело, что скачав какое-нибудь видео оно не открывалось без бубна и скачивания плееров, кодеков и прочего на венде, когда на Linux и BSD были всякие xine, умеющие почти все кодеки из коробки и показывающие корректно недокаченные файлы. Но дело не в этом, а в рекламе. Толкали бы какую-нибудь Ubuntu с теми же бюджетами, как толкают Windows, у Ubuntu было бы сейчас 146% десктопа.

«программа должна выполнять одну функцию и выполнять её хорошо»

Угу, поэтому две программы сходного прикладного назначения имеют разный набор ключей. Отдельно хочется упомянуть однопоточность/однопроцессность половины этих инструментов, так «хорошо» выполняющих свою функцию. Usability во все поля.

А что есть объект в вашем изложении?

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

А что, сложно передавать текстом объекты каким-нибудь json или списками лиспа?

Можно передавать хоть видео. Но это между своими программами. А проблема в том, что между стандартными утилитами (+ shell'ом) передаётся текст, который надо парсить. И это проблема. Достаточно посмотреть, сколько способов выстрелить в ногу когда в имени файлы встречается банальный пробел.
Был бы единый формат передачи бинарных данных между стандартными утилитами и командным интерпретатором, таких проблем не было бы.

Спасибо

Не текстовая ли передача данных считается фишкой и сильной стороной никсов?

Вот я не пойму, откуда вы такие умные берётесь и почему думаете, что вы умнее тех, кто был до вас. На чём строится ваша уверенность? Просто на самомнении буд-то вы более квалифицированный специалист, чем разработчики unix? Ну это же не серьёзно, ей богу.

Ну не было бы этой проблемы, хотя это не проблема в целом, но были бы другие проблемы. Например: единого формата бы не было в любом случае, потому что то, что люди называют стандартными утилитами создавалось в разное время разными людьми и компаниями, а значит были бы разные бинарные форматы с разной последовательностью байт и разными зависимостями для их разбора. Думаешь все бы тупо упаковывали сишные структуры в сетевой последовательности? А хрен бы там. Был бы сто + 1 бинарный формат. Попробуй ко поработать с этим потом из шела. Кроме того текстовые форматы всё равно бы использовались, потому что это удобно, а значит было бы ещё больше проблем.

Был выбран наименее геморройный и просто в реализации вариант. А как пришли неофаги, так они сразу сосредоточились на мелких проблемах и возвели их в абсолют.

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

Покажите ка этот пункт из какого-нибудь манифеста unix, если найдёте что-то подобное. Фишкой считается комбайнирование программ. И прикол в том, что эта фишка в силу своего удобства перекочевала в большинство современных ОС. Вот настолько это сильная сторона. Она даже перекочевала в различные фреймворки и используется там не прямо, а по духу так сказать, в каком-нибудь gstreamer например.

А то что хипстеры не понимая откуда ноги растут, заостряют своё внимание именно на передачу текста в ls | grep «trulala» и при этом не понимают что с тем же успехом можно сделать и бинарные варианты этих программ, это же хипстеры. Хипстеры они как дети, не понимают от слова совсем, только рефлексируют на часть предложения.

не понимают что с тем же успехом можно сделать и бинарные варианты этих программ

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

Но ведь это не сложно сделать, почему если это так нужно прогрессивным людям, они всё ещё не прислали свои патчи в binutils, coreutils и тд. Добавили бы в виде флага какого-нибудь –bin и для удобства симлинки. То есть это как раз тот случай, когда реализация стоит минимум и ломать ничего не надо. А значит изначальный план верный.

откуда вы такие умные берётесь и почему думаете

А вы откуда берётесь, что молитесь на старые решения? Всё было сделано идеально, нельзя было сделать лучше? Безусловно, Unix делали очень умные люди. Но это не значит, что каждое их решение является верхом совершенства. Также совершенно не значит, что все решения, которые были уместны тогда, подходят и сейчас. Периодически надо выкидывать старое и менять на новое потому, что мир меняется, задачи меняются, средства и инструменты развиваются...

Отвлечёмся от передачи данных между утилитами на секунду. Тут в первом сообщении говорится о языке C. Если бы создатели языка (они же и создатели Unix) выбрали другой формат строк, где вместо маркера конца указывается длина, то только одно это позволило бы избежать огромного количества проблем. Не появился и не существовал бы целый пласт уязвимостей. Это прекрасный пример не самого удачного решения.

Или можно посмотреть на устройство драйвера терминала в Linux (где-то у меня была ссылка на подробную статью), там до сих пор живёт код времён бумажных teletype'ов. Стоит ли всё это сохранять на века? Не пора ли сделать новую концепцию командной строки, но с более богатыми возможностями? Кстати, ты же в курсе, почему в mc для выхода из редактора надо два раза Esc нажимать? Вот! Ещё один пример прекрасного, гениального решения, которое надо обязательно сохранить навсегда.

К утилитам...

Был бы сто + 1 бинарный формат.

А сейчас не так разве? Только формат текстовый. Разные утилиты имеют разный формат ключей («k val», "-k val", "-key val", "--key val", "--key=val", даже "-kVal"), разные форматы текстового ввода и вывода. Из общего стандартного только то, что >>обычно<< разные поля одной записи можно разделить по пробельным символам. И когда нужно сделать что-то чуть сложнее двух строк, особенно когда данные сами содержат пробелы (а также переносы строк и другие неожиданные символы) начинаются особые упражнения с awk, sed, экранированием в bash'э всего и вся и кучей правил «как не выстрелить в ногу». Насколько было бы проще, если бы вывод утилит был хоть немного форматированным. Пусть даже текстовым, но с разметкой, с форматом. С заголовком в начале вывода, вроде «тут у нас есть 6 колонок, вот их названия и типы». При этом колонки не разделять пробелами, а указывать их размеры.

CTSS, DTSS уже в 60-е были. Не говоря уже про OS/360 с зачатками виртуализации. Unix тут не был никаким пионером.

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

А вы откуда берётесь, что молитесь на старые решения? Всё было сделано идеально, нельзя было сделать лучше? Безусловно, Unix делали очень умные люди. Но это не значит, что каждое их решение является верхом совершенства. Также совершенно не значит, что все решения, которые были уместны тогда, подходят и сейчас. Периодически надо выкидывать старое и менять на новое потому, что мир меняется, задачи меняются, средства и инструменты развиваются…

да где же вас, хипстеров клепают? руль и колесо давайте заменим … потому что новые инструменты появились, новые долбо… люди-хипстеры с синдромом NIH понавылуплялись…

да и чем подход «все в одном большом говноподелии» так нов, стилен и молодежен ? такое же старье.

руль и колесо давайте заменим

Руль уже скоро пропадёт в большинстве автомобилей. А колесо применимо далеко не везде, где-то гусеница лучше, где-то винт и крыло...

да и чем подход «все в одном большом говноподелии» так нов, стилен и молодежен

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

Всё очень просто, когда вы работаете с в индустрии хотя бы более 5 лет, то начинаете ценить преемственность. Кроме того, начинаете понимать, что мало что вообще поменялось за эти 50 лет. Фантазировать можно сколько угодно, но если выкинуть старый код, но будет работать вообще ничего. Ни платёжные системы, ни банковские операции, ни персональные компьютеры - ничего. Всё держится за счёт преемственности. Даже новые проекты новые они только сейчас, через 5 лет они уже не новые и также начинают держаться за счёт преемственности. Но главное здесь то, что решения принимавшиеся инженерами тогда актуальны и сейчас, потому что ничего не поменялось радикально. Отсюда и мнение такое как у меня. Я не молюсь на старые решения, но я понимаю почему они были такими, не протестую против них, просто живу и часть этих решений нахожу элегантными и верными.

Что до С, то ну хранить длину строки, ну будут другие проблемы вроде сколько байт выделять на длину, как писать длину если тексто передавать и тд и тп. Проблем достаточно в каждом языке и это очевидно любому, кто освоил хотя бы парочку. Решая одну проблему люди часто создают ещё парочку проблем. Иногда лучше остановится на простом элегантном топорном решении, оно будет надёжнее и навека, чем каждый год решать всё новые проблемы.

И да, мне никак не мешает наследие терминалов и телетайпов. Если на то пошло, то почему вообще на локалхосте мы используем этот термин терминал, почему бы не использовать command line, почему бы не сделать его исключительно графическим хотя бы чисто поверх fb, но именно графическим, то есть рисовать всё каким-нибудь фреймворком минимальным прямо в буфер? Ответ - всё готово, если вам надо - сделайте. Если кому-то будет нужно - этим будут пользоваться. Понимаете в чём дело - всё же можно сделать и всё это возможно благодаря такой вод пофигистической философии, заложенной в основу - пусть растёт 100 цветов. Представьте себе на минуту, что была бы единственно верная командная строка, впиленная так, что не выпилишь и аналогов не напишешь. Но не так же сделано. Не хочешь - не используй, напиши своё. Но тут дело в том, что огромное количество народу использует терминал что так что по другому и кому-то даже может быть то телетайпо наследие пригождается. Каждый день использую более 10 терминалов некоторые к локалхосту, некоторые к виртуалкам, некоторые к удалённым машинам - всё устраивает полностью, не вижу проблемы совершенно.

Что до стандартов выхлопа, то я и говорю, что всё можно сделать в рамках того что есть. Никакой проблемы нет. Если бы был выбран бинарный вариант, то были бы параллельно и текстовые и куча бинарных форматов. Избежать этого было бы можно только навязав всем один единственно правильный бинарноориентированный шел с единственно верным бинарным протоколом взаимодействия(пример power shell), вы что, этого хотите? Так это ещё хуже в итоге было бы.