Логика и терминальные системы

Терминальные системы - штука интересная во многих смыслах.

Во-первых, интересна история развития терминалов и идей, на основе которых они создаются. Во-вторых, интересны (хоть и достаточно очевидны) области применимости терминальных систем.

Первые терминалы были по сути интерпретаторами некоторого простого командного языка. Целевой машиной для этого языка была как бы каретка (курсор), "ползающая" по полю из клеток размером 80*24 (или другому, не важно). С помощью языка можно было приказать каретке напечатать в клетке символ, стереть его, командовать перемещениями каретки в абсолютной системе координат (по всему полю) и относительной (например, относительно текущего положения каретки). Ну и всякое еще.

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

Затем - X-терминалы. Уровень протокола, на основании которого строилось общение хоста и терминала, стал еще выше.

И...

И все.
Точка реализации "в железе" интерпретатора, исполняющего X-протокол на целевой машине растрового графического дисплея, стала точкой перегиба.

Все следующие терминалы - графические, - по сути стали даже более простыми, чем их алфавитно-цифровые предки. Если в последних со временем возникли даже такие "излишества", как подгружаемые с хоста шрифты, терминалы новой волны "понятия не имеют" ни о чём, кроме фрагментов памяти растрового дисплея. В самом упрощенном виде принцип их работы независимо от протокола следующий - если программой, исполняемой на хосте изменена какая-то область растровой памяти, то эти изменения передаются по сети и отображаются на экране терминала. Это позволяет снизить нагрузку на сеть и повысить быстродействие системы в целом (за счёт того, что не требуется передача всего буфера экранной памяти, как при ее регенерации, а только фрагментов). Иначе все эти терминалы можно назвать устройствами удаленного отображения буфера кадров, как-то так.

Вот здесь уже можно задать вопрос - почему разработчики отказались от повышения интеллекта терминала (усложнения понимаемого им языка) и пошли по пути принципиального упрощения?
Однозначно верного ответа быть не может, но соображения кое-какие есть.
Во-первых, вполне возможно, что так поступить - правильно. Потому что начиная с какого-то уровня сложности протокола передача обновленных кусочков буфера кадра может оказаться более эффективной.
Во-вторых, - потому что невозможно создать единственный графический API на все случаи жизни и отобразить его вызовы на единственно верный язык и протокол общения хоста и графического терминала.
В-третьих, - потому что рост сложности языка и протокола приводит к росту сложности реализаций, а она - к снижению безопасности. Знаменитые эксплойты X Window надолго остались в памяти.
Можно придумать ещё несколько пунктов.

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

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

Кстати, алфавитно-цифровые терминалы никуда не делись.
И производятся.
Причём, что самое интересное - в том числе и компанией, купившей в своё время у почившей DEC... терминальный бизнес.
Такой вот парадокс - DEC уже давно нет, а в свое время (в 1995 г.) прикупившая кусочек гиганта SunRiver Data Systems переименовалась и живёт и здравствует до сих пор.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365