UNIX-way как следствие превалирования C

Нет

Юниксвей это следствие крайней примитивности инструментов разработки в 70-х годах. Если малейшее движение грозит отстрелом ног, то лучше делать как можно меньше движений.

Философия UNIX это ответ на окружающую действительность времени появления и становления UNIX, т. е. слабые вычислительные способности, малое количество разработчиков, отсутствие сфомированного рынка с высоким спросом и высокими требованиями. Это время прошло.

Думаю, причина в появлении многозадачности и mmu, а так же большого количества ресурсов. Если в мире однозадачного DOS эффективнее было делать программу-ОС под конкретное обопудование, сразу делающую всё чтобы не держать в памяти ничего лишнего, то в unix под конкретное оборудование писалось ядро ОС, а программы должны были быть компактными, отвечающие только за свою функцию и быть переносимыми. Если сделать громоздкого монстра то терялся смысл многозадачной ОС, да и монстр едва ли мог быть переносимым. Так что это не заслуга конкретно Си, а высокоуровневых языков. И во времена появления юниксвея си был как раз наиболее высокоуровневым, а не низкоуровневым языком. Это потом появилось всякое ООП, а тогда писали на ассемблере

Вот что интересно, как после всей этой UNIX-Way философии и KISS пропаганды в мире UNIX появилось такое комбайное дерьмо, как реализации X11?

Но что самое интересное, так это то, почему ранее Linux-сообщество которое так радело за философию GNU (GNU’s Not Unix!) с огромной радостью втянуло этот иксовый комбайн, обмазанный проприетарными расширениями (вспоминаем IRIX) в себя и не захотело написать нормальный оконный сервер, как сделали те же разработчики OS X? См. https://developers.slashdot.org/comments.pl?sid=75257&cid=6734612

Десятилетиями Linux-разработчики отпиливали и выкидывали куски подсистем иксового копролита сначала от XFree86, потом от X.Org, чтобы на выходе так и не побороть тиринг и не исправить чудовищные проблемы с безопасностью.

Но что самое смешное, так это то, что разработчики официального продолжателя традиций UNIX – Plan9, выкинули X11 сразу на помойку и написали компактные 8½ и rio, которые действительно следовали UNIX-Way и KISS.

а тогда писали на ассемблере

Да не, просто на фортране системное программирование никакое, а на бейсике - смешно.

иксовый сервер не для unix, а для терминалов. Ему не нужна многозадачность вообще. Многозадачность на сервере, а на терминале тонкий клиент - эти самые иксы. Логическое продолжение vt100/vt220/vt320 но для графики

Многозадачность на сервере, а на терминале тонкий клиент - эти самые иксы

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

обмазанный проприетарными расширениями (вспоминаем IRIX)

Коллега, а напишите, пожалуйста, подробнее про расширения Xsgi. Что ещё там было, кроме Display PostScript?

P. S. Display PostScript, кстати говоря, был интересной идеей (с т. з. пользователя), хотя с т. з. инженера по безопасности, наверное, кáка.

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

Мне надо. Что такое функция в этой фразе?

Что ещё там было, кроме Display PostScript?

Например, там была реализация PHIGS – PEX, который был альтернативой IRIS GL (OpenGL). К сожалению, этот графический API забыт и совсем уж экзотика. На GitHub’е недавно обнаружил исходники, удивился что там кое-где Fortran: https://github.com/n1ckfg/Phigs

Наверное SGI поддерживали конкурирующий стандарт, потому что он тогда был мейнстримом и у всякой уважающей себя компании имелась своя реализация PHIGS – DEC PHIGS, IBM’s graPHIGS, Sun’s SunPHIGS и т. д.

Кстати у первых Solaris’ов ещё было такое графическое API, как XIL. Насколько я помню, с иксами не связанное, хотя могу ошибаться. Знаю, что официальный порт Quake II под Unix’ы, в т. ч. Solaris содержал в себе библиотеку ref_xil.so, которая использовалась для рендеринга с помощью XIL:

https://github.com/ZaneA/Quake-2/blob/master/README.Solaris
https://stuff.mit.edu/afs/sipb/contrib/idgames/share/quake2/baseq2/

Не только с иксами так. Емакс ещё.

Emacs’у комбайность простительна, он не системный компонент операционной системы, полвека запускавшийся от root’а.

Царизм как следствие превалирования Царя

Нету никакого Юниксвея.

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

Этот принцип можно понимать по-разному. Кто-то в одной функции видит одну функцию, а кто-то лапшу из множества подфункций, которые нужно разнести на отдельные функции.

Возьмем ядро Линукса или Юникса. Для одних это одна функция - ядро операционки. Для других - монолитная помойка, которую надо разделять на микроядра и микросервисы, работающие в изолированных адресных пространствах, взаимодействуя посредством сообщений.

Спасибо.

Про XIL я знаю и, кажется, что-то из моего железа умеет в аппаратно-ускоренный XIL. Quake II действительно может выполнять рендеринг через XIL, но, независимо от способа рисования, с производительностью там всё грустно – 15 FPS.

Т. е. и XIL, и OpenGL на SPARC годятся разве что для CAD-систем, ни никак не для Quake.

XIL был до того, как OpenGL стал распространён, т. е. уже в 2000-м году (Solaris 8) был объявлен устаревшим.

Про PHIGS до сих пор не слышал ни разу, спасибо.

Сишка не при чём. А лапша на баше с пайпами - худшая идея из возможных. Ещё и дико медленная.

Но что самое интересное, так это то, почему ранее Linux-сообщество которое так радело за философию GNU (GNU’s Not Unix!) с огромной радостью втянуло этот иксовый комбайн, обмазанный проприетарными расширениями (вспоминаем IRIX) в себя и не захотело написать нормальный оконный сервер, как сделали те же разработчики OS X? См. https://developers.slashdot.org/comments.pl?sid=75257&cid=6734612

Думаю разгадка очень простая: захотели более легкого переноса и совместимости с имеющимися программами для X-терминалов в больших юниксах. Кроме того, в начале 90-х иксы еще не выглядели настолько проблемными как в лет через 15-20.

И может самое главное и неприятное для сообщества - это, что не осилили. К сожалению, «базарным» методом легко получается разрабатывать в основном то на, что уже есть какие-то спецификации. Поэтому при наличии Posix, RFC и стандартов де-факто на разные утилиты и т.п. разработка велась достаточно быстро и качественно.

А вот, когда готовых стандартов нет и надо что-то разработать, требующее исследовательской работы (и не на пару часов), то как-то так не очень получается. Впрочем, у коммерческих производителей тоже как-то не очень, если это не крупняк какой, вроде IBM или Microsoft с ее Reserch отделом.

Юниксвей это следствие крайней примитивности инструментов разработки в 70-х годах. Если малейшее движение грозит отстрелом ног, то лучше делать как можно меньше движений.

Соглашусь, сам пробовал писать cgi-script на C - малейшее движение в сторону(или ошибочка, недочёт) и всё по ***де идёт.

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

Не понял, как этот вопрос соотносится с первыми двумя абзацами?

Этот принцип можно понимать по-разному. Кто-то в одной функции видит одну функцию, а кто-то лапшу из множества подфункций

Наверное, под функцией имеется в виду какая-то законченная функциональность, нужная пользователю, use case. Например, отсортировать последовательность строк, убрать из нее элементы, не соответствующие шаблону и т.д.

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

нет. unix-way появился тк в отличии от DOS где надо было писать софтину которая делала все, можно было это разделить тк появился mmu и можно было в многозадачность.

проблема в том, что он не соблюдается, в том же лялихе, ядро - монолитная свалка и комбайн (бсди тоже самое), сустемдик - тоже кусок монолитного гавна, который хочет быть всем и ничем и таким и является, вейланд, который типа «иксы писали дидыыыы, нам подавай новое стильное молодежное» подразумевает то что композитор будет уметь все, то есть кусок монолитного гавна (в тех же иксах есть wm отдельно, в вейланде этого нет by design, там композитор).

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

Это время прошло.

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

слабые вычислительные способности, малое количество разработчиков, отсутствие сфомированного рынка с высоким спросом и высокими требованиями.(с)

и не захотело написать нормальный оконный сервер, как сделали те же разработчики OS X?

У Mac OS X одна компания-разработчик, один взгляд на вещи, одни рекомендации разработки. Делать всё с нуля в Линуксе сообщество бы не потянуло.

А лапша на баше с пайпами - худшая идея из возможных. Ещё и дико медленная.

А на коньках, в гамаке и стоя ваще ппц.

Комбайн современности - хром. Ну или лиса.

Все счастливы? Нельзя раздерибанить на DOM, CSSOM, Renderer и обвес? Да щас.

У Mac OS X одна компания-разработчик, один взгляд на вещи, одни рекомендации разработки. Делать всё с нуля в Линуксе сообщество бы не потянуло.

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

Пиши ещё, а лучше займись программированием более-менее профессионально и сразу поймёшь почему так.

Если совсем просто, то это для того, чтобы развивать отдельные части довольно крупной системы максимально дёшево. Ни один другой способ декомпозиции сложного ПО не даёт такой гибкости по сумме возможностей. Тут и разные языки можно использовать, любой протокол между программами и всё это даром. Отладка опять же максимально проста, потому что каждую маленькую программу достаточно легко потестить отдельно чем бы она не занималась. Поэтому и сошлись на таком способе. Кроме того он почти не приносит накладных расходов при правильном использовании. Потом люди стали двигаться дальше и подумали, что другие способы вроде как тоже ничего себе.

ref_xil это ещё один ref_soft, просто там xil используется для вывода на экран. Тогда была проблема с получением наиболее прямого доступа к видеопамяти. Где-то vga/svga напрямую дёргали, а где-то библиотеки были. А иксами рисовать тогда было слишком медленно

В смысле не потянуло? Не напомнить вам, что именно сообщества gnu, bsd и mit как раз всё и потянули с нуля, а Mac OS грамотно вожрала в себя то, чего не смогли сделать с нуля сами.

Если уж упираться в эту тему, то пожалуй не apple, а ms смогла, но там тоже не всё так гладко и многое держится на субподряде, других компаниях и инвестициях.

quake использует xil для вывода уже отрендеренной картинки на экран.

компактные 8½ и rio, которые действительно следовали UNIX-Way и KISS

Действительно архитектурно интересные решения. Но, в рамках Plan9 они применялись (насколько я знаю, поправьте, если не так) только для простой 2D графики. Как бы оно выглядело с 3D, с ускорением видео, поддержкой экранов с разным DPI, с управлением цветом? Не обросло бы костылями?

Однако проскочила мысль, почему так получилось

В двух словах это сложно объяснить. Но если попытаться, то наверное нужно сказать, что это была реакция на зашедший в тупик «старый подход». Попытка выкинуть горы древних костылей и запилить всё с чистого листа с новыми, чистыми абстракциями. UNIX и C были ответом на загибающиеся под своей тяжестью OS/360 и PL/I. Новой реальности, с новыми компами нужны были новые, лёгкие, гибкие инструменты.

Почему вместе с C в составе UNIX введено несколько мощных языков, как язык сценариев или AWK?

Конкретно это объясняется как раз новой идеологией «всё есть файл» и «всё есть поток байт». С потоком байт нужно уметь как-то работать, в т.ч. выделять из него различные структуры. Просто посмотри на JCL, чтобы понять, насколько UNIX был проще, и в месте с тем мощнее.

следствие крайней примитивности инструментов разработки в 70-х годах

Они были примитивные, но при этом сложные в своей примитивности. Как китайская письменность.

в отличии от DOS где надо было писать софтину которая делала все, можно было это разделить тк появился mmu и можно было в многозадачность

DOS тут вообще ни чём. Многозадачные ОС существовали очень давно, т.к. компы были убердорогие и простаивать было нельзя. Наоборот, это DOS появилась как вырожденная ОС для дешёвых компов.

У Mac OS X одна компания-разработчик, один взгляд на вещи, одни рекомендации разработки.

Ядро Linux развивает «благосклонный диктатор» со своим виденьем. Что мешало сделать нечто подобное для графики?

Наверно, то же, что помешало сделать нечто подобное для системы инициализации.

Однако у дешёвых оболочек графическая система была частью ядра.

DOS тут вообще ни чём. Многозадачные ОС существовали очень давно, т.к. компы были убердорогие и простаивать было нельзя. Наоборот, это DOS появилась как вырожденная ОС для дешёвых компов.

под DOS имел ввиду любую однозадачную ОС с подходом все-в-одном. и система планирования задач да были, но то было немного другое.

Ядро Linux развивает «благосклонный диктатор» со своим виденьем.

помойка … ну развивает да, и дальше что?

Что мешало сделать нечто подобное для графики?

спасибо, но не надо.

Что ещё там было, кроме Display PostScript?

Хм... Раньше в X'ах был DPS? Не знал.
Интересно, почему не взлетело?
Кстати, ещё интересно, почему не стал популярным OPENSTEP (GnuSTEP)? Могла бы быть практически macOS на ядре Linux.

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

ну видимо писание лапшекода пересилило, прочесть спеку про openstep еще надо, подумать, а тут ниче не надо - пиши себе лапшекод, принимай вещества да и получай свой гноме 3 с вяйлендом.

Чем спека OpenSTEP отличается от спеки POSIX, что одну взяли, а другую - нет?

Чем спека OpenSTEP отличается от спеки POSIX, что одну взяли, а другую - нет?

ну posix куда более распространен и немного все же другой уровень. плюс там objective C ну то есть там не один фактор, далеко не один. потом - openstep это не вся графическая подсистема, gnustep без иксов не работает.

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

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

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

Как раз таки для графики тоже много всего и никаких проблем с этим нет. Есть fb, есть directfb, есть X, есть wayland, можно хоть на fb + sdl писать если хочется. Собственно никто не мешает вот взять Gnome4 и запилить вообще без этих ваших дисплейных серверов и строго говоря так оно и есть, учитывая что wayland это просто протокол, а гном уже давно сам себе режисёр.

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

quake использует xil для вывода уже отрендеренной картинки на экран.

Всё верно. Но не только лишь все видеокарты умеют в XIL (особенно сегодня). Напр., под Sun Creator и Sun Elite (это такие огромные платы, втыкающиеся в шину UPA) отдельным пакетом шли именно XIL-драйвера (/usr/openwin/lib/xil/devhandlers/*).

и, кажется, что-то из моего железа умеет в аппаратно-ускоренный XIL

Если у тебя есть SPARCstation или Sun Blade, то скорее всего он.

Quake II действительно может выполнять рендеринг через XIL, но, независимо от способа рисования, с производительностью там всё грустно – 15 FPS.

Рендер XIL кстати в Quake II id Software сами официально добавили. Как сборки под Alpha/AXP.

P.S. Порт XIL кстати есть на Linux, через X11: https://github.com/HansKramer/OpenXIL, я его вот прямо сейчас собрал, но там всё где-то падает, а мне лень отлаживать и разбираться.

Про PHIGS до сих пор не слышал ни разу, спасибо.

Интересная штука, да:

https://sourceforge.net/p/phigs/wiki/Home/

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

лапшекод, принимай вещества да и получай свой гноме 3

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

gnustep без иксов не работает

Что именно из X11 там используется? Примитивы же он не использует, просто создание окна и заполнение его картинкой.
Кстати, делает он это каким-то особым интересным способом. Давно его тыкал, ещё до появления композиторов. Заметил следующую интересную особенность. Если остановить процесс какого-нибудь Gnome или KDE приложения, потом по его окну провести другим, то содержимое сотрётся, останется только цвет фона. Если такое проделать с окном приложения GnuSTEP, то его содержимое остаётся. Видимо, он использует какой-то дополнительный буфер на стороне X-сервера. Backing store? Почему это больше нигде не использовалось до появления композиторов?

Никакой. Судя по всему это какой-то минимальный GUI тулкит поверх libXt.