Pull to refresh

Comments 36

Про скорость работы по ssh -X.
Основных проблем там 2:

  1. X11 в общем и целом - синхронный протокол, и он чувствителен к задержке.

  2. С определённого момента (приблизительно в 2009-2010-м), софт в linux плавно переполз на client-side шрифты. Если до этого шрифты рисовал X-сервер и ему шли команды "нарисуй вот этим шрифтом вот здесь", то после это рисовалось на стороне клиента и серверу уходил bitmap. Что облегчало работу локальную, но ломало к чертям работу с удалённым протоколом.

Собственно - я видел среду, где особенности X11 использовались по-полной (thick client, на клиентской стороне запускался браузер - как наиболее требовательное) и оконный менеджер. Остальной софт на сервере. Работало это достаточно быстро, чтобы не замечать задержки. (100Мбит сеть, по-моему вообще бездисковые локальные машины, но я внутрь не заглядывал).

X11 ни разу не синхронный. С 2 согласен. А то что вы видели скорее всего к X11 не имело отношение. Это было web тонкий клиент и обмен по сети происходил через http.

Я там работал. Думаю, уж мог отличить, как там X11 настраивался и как там это было сделано ;-)

PS. всех деталей за давностью лет уже не помню.

Вы о чем? О тонком клиенте или о X11 протоколе?

О тонком клиенте.
Про X11 я точно знаю, что он сильно чувствителен к задержкам сети, и одними из переработок в NX (который NoMachine), были как раз меры по снижению этой чувствительности.

Все сетевые протоколы чувствительны к задержкам. В X11 это ясно осознавали и сделали его так, чтобы свести эту чувствительность к минимуму. Я писал клиент который прямо работал с протоколом и поэтому точно знаю. Если вам прямо нужно чтобы GUI приложение работало отдаленно, лучше чем X11 не придумано. Но есть одно условие. Использовать X11 полностью и как задумано, а не рендировать на клиенте и пересылать на сервер картинки, как делают современные GTK/Qt.

Видимо никто так и не научился использовать X11 "как задумано". Потому, что по моему опыту, если более-менее тяжёлое приложение работает удаленно, то оно тупит даже в локалке. И это касается всего, включая нативные проги из коробки.

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

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

А «правильно» X11 использовали старые тулкиты – например motif. Это и сейчас можно протестировать и работать должно очень быстро.

есть отдельный класс инструментов удаленного управления, когда передается весь экран как сжатый видеопоток, есть отличная технология sunshine+moonlight (открытые) или закрытый steam link (мне кажется они на одной и той же основе сделаны), работает просто шикарно на очень тонких клиентах в локальной сети можно играть (лаг доли секунды) и смотреть видео.

Так работает, не спорю. Но передавать растр это костыль. Как бы хорошо он и не работал. А X11 это принципиально другое решение. Кстати, вот вы говорите «в локальной сети» – а ведь X11 работает нормально даже через медленный Интернет – 33к например или 56к. Вот, представьте себе nano через ssh. Вот так приблизительно работает и X11 через SSH.

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

Есть RemoteFX от майкрософта, как штатная фича rdp (но только с майкрософт сервером) которая позволяет делать видеокодирование всего или части экрана.

А можете еще написать статью про подключению GPU к Linux и как с ним xserver и wayland-compositor работают?

В смысле, подключение?

Если правильно помню
- X11 работает, используя драйвера из /usr/lib/xorg/modules/drivers, по умолчанию modesetting, но можно поменять в /etc/X11/xorg.conf
Туда можно добавить "фирменные", если они есть в природе.


- Wayland работает с устройствами /dev/dri/cardX и /dev/dri/renderD128, которые создает драйвер в ядре. Т.е. нужен модуль ядра для GPU.

Спасибо! с 2004 по 2009 даже дома сидел на Linux, как Netware admin выбил себе даже курсы по OpenSuse и всю эту внутреннюю "механику" понимал, а потом увлечение фото - Lightroom - Винда. А сейчас на работе и сервера Linux и рабочая станция а глубокого понятия не хватает, старое знание забылось а времени сесть почитать разобраться нет.
И тут ваша статья!

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

Т.е. пусть даже в режиме immediate mode, выходит что пикча должна запаковаться в tcp, потом снова распаковаться и отрисоваться на GPU?

И ещё может быть shared memory.

может через сокет: в сокет записалось - из сокета вышло. Это чисто программная "точка обмена".

Кроме того, там всё-таки драйвер, работа с памятью GPU, рендеринг если драйвер поддерживает. По сети передаются команды управления - ну и битмапы, если вы их загружаете

Стоит наверно добавить:
XWayland - DDX-компонент(Device-Dependent X), обеспечивающий запуск X.Org Server для организации выполнения X11-приложений в окружениях на базе Wayland.
Выходят периодически корректирующие выпуски X.Org Server и XWayland(закрывают уязвимости)
https://gitlab.freedesktop.org/xorg/xserver/-/tags/
Для удаленного доступа: Xpra, X2Go, SPICE, NoMachine(Free - Concurrent connections 1)
Брал инфу из ALT Linux Wiki - для общего понимания норм.

Наикрутейшая фича xserver - множество рабочих мест на одной физической машине (когда на каждое рабочее место запускается свое приложение X (или Xephyr или чето там удобно) и у каждого пользователя свой терминал (монитор, мышь, клавиатура,..) и все это работает максимально эффективно. В linux, при использовании xserver, поддержка настройки всего этого - встроена (loginctl).

Так вот, в wayland так пока не умеет и боюсь разработчики забили на эту фичу и не собираются ее реализовывать.

Потому что GNU/Linux всё же не Unix. Компьютеры, на которых работал тогда Юникс и придумывались Иксы, по назначению и параметрам не то же самое, что нынешние серверы и рабочие станции под ГНУ/Линукс.

Очевидно, что сейчас немного желающих соорудить из какого-то компа мейнфрейм и подключить к нему сотню-другую терминалов. 99,999... % пользовательских сессий по работе с ОС локальны. По сети общаются лишь клиенты и серверы (могут быть и промежуточные, но сути не меняет). Горстка админов, имеющих удалённый доступ, статистику не меняет.

Как подключить к одному компьютеру 4 видеокарты и 4 монитора - знаю.
Как запустить на них разные сессии для разных юзеров - представляю.
Как распределить 4 клавиатуры и 4 мыши - догадываюсь.

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

как подключить хотя бы 10 мониторов

3 видеокарты или мониторы display port с технологией Multi-Stream Transport (MST) или DisplayPort Daisy Chaining. с DP можно вообще с одной видеокартой обойтись (туда пихают по 4 DP каждый из которых, даже если это древний dp1.2 позволят подключить по 5 мониторов fullhd60hz)

И главное, зачем? )

Серьезная экономия на железе.

Когда то я на windows (та же технология, софт ibik aster) работал и играл в двоем на одной машине, сэкономив заметные суммы денег.. да и сейчас собственно у меня на базе linux такой конфиг, с ним даже нет проблем, типичных для windows с играми (steam запускается в песочнице и почти не видит соседа, почти, это потому что я нашел игру что умудрилась помешать соседу но это настраивается)

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

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

Если о графике, то ничего не сказано про свободный графический драйвер nouveau для NVIDIA.

это потому что он хоть свободный, хоть не свободный - на архитектуру X11/Wayland не влияет от слова никак.
Просто еще один драйвер среди других драйверов.

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

объективно, для AMD нет подобного драйвера.

А как же radeon -- который открытый

он OpenGL и многе другое для Radeon не поддерживает.

ls /usr/lib/xorg/modules/drivers/
amdgpu_drv.so  fbdev_drv.so        nouveau_drv.so  vesa_drv.so
ati_drv.so     modesetting_drv.so  radeon_drv.so   xrdpdev_drv.so

не оно разве там?

Как-то не очень показались мне диаграммы. Решил посмотреть как это будет в пиаримом Obsidian.

Результат
Вариант диаграммы VNC
Вариант диаграммы VNC

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

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

Вот, прекрасный софт для рисования диаграмм )

Намного лучше чем в Офисе.

А можно подробнее как вы это делали?. Плагины, данные для них.

Только встроенный Canvas, технически это тоже плагин но он просто есть.

Выдернул из статьи картинки чипа, мыши, клавиатуры и монитора при помощи Spectacle - стандартной утилиты для скриншотов в KDE Plasma, сложил в vault специально предназначенный для экспериментов с Obsidian.

В новый canvas набросал cards. Текст, цвет и соединения - очень интуитивно мышью. Режим snap to grid выключен как ограничивающий твроческую фантазию, snap to objects включён чтобы прямые соединения были в точности прямыми сами по себе.

В карточки с графикой - отображаемые ссылки на картинки, типа

![[Keyboard.png]]

В карточку с Apps - прямо HTML

<div style="position:relative; top: 0.3rem; left: 0.3rem;">
<div style= "position: absolute; top:0rem; left: 0rem; border: 0.1rem solid blue; background:#F0FFF0; height: 4rem; width: 6rem">
</div>
<div style= "position: absolute; top:0.6rem; left: 0.6rem; border: 0.1rem solid blue; background:#F0FFF0; height: 4rem; width: 6rem">
</div>
<div style= "position: absolute; top:1.2rem; left: 1.2rem; border: 0.1rem solid blue; background:#F0FFF0; height: 4rem; width: 6rem; display: flex; align-items: center; justify-content: center;">
Apps
</div>
</div>

Общий div - Obsidian воспринимает каждый элемент HTML как вставку в текст, даже если текста нет, поэтому нужен.

Правую и левую части объединить в группы.

Всё.

И видим - поля вокруг картинок не убираются, и через HTML тоже не до конца. Цвет фона карточки определяется цветом границы. Толщина соединяющих линий не выбирается, линии только сплошные, выбора вида стрелок тоже нет. Если тянуть на canvas заметку или изображение, то они обязательно помечаются именем файла.

То есть быстро, просто и не особо прекрасно. Obsidian в доках ссылается на стандарт которому соответствует canvas, значит может быть имеет смысл его посмотреть и редактировать диаграмму как текст, не пробовал.

В случае Windows понятно: начиная от запуска десктопных бизнес‑приложений на сервере до «рядовых», программ, потому что все они — GUI.

На Уиндоуз нет консольных приложений или приложений, работающих без каких бы то ни было окон, типа сервисов/демонов?

P. S.: Стиль текста больше не статью напоминает, а стенографию разговора в курилке. Надо было бы нейросетям отдать заготовку вашу полезную по содержанию на переработку. А, грамматику можно проверить перед публикацией, нажав F7 в текстовом процессоре. Уж больно не читаемо местами... (Как в приведённой же цитате, например.)

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

А некоторые и вовсе пишут так, как будто составляют пояснительную записку к НИОКР по НЖГБД РКЦЦ МГОУБ ИРГГ.

Предлагаю глянуть близкую по сути статью https://habr.com/ru/companies/lanit/articles/516330/ ("Как устроена графика в Linux: обзор различных сред оформления рабочего стола")

Я там тоже чуть про X показал примеров. И много скриншотов про среды рабочего стола (KDE/GNOME и т.д.)

Sign up to leave a comment.

Articles