forum.opennet.ru - "Первый стабильный выпуск проекта Linux Remote Desktop" (97)

"Первый стабильный выпуск проекта Linux Remote Desktop"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Первый стабильный выпуск проекта Linux Remote Desktop"	+1 +/–
Сообщение от opennews (??), 30-Дек-21, 14:28
Доступен выпуск проекта Linux Remote Desktop 0.9, развивающего платформу для организации удалённой работы пользователей. Отмечается, что это первый стабильный выпуск проекта, готовый для формирования рабочих внедрений. Платформа позволяет настроить Linux-сервер для автоматизации удалённой работы сотрудников, дающий пользователям возможность по сети подключаться к виртуальному рабочему столу и запускать предоставленные администратором графические приложения. Доступ к рабочему столу возможен как при помощи любого RDP-клиента, так и из web-браузера. Реализация управляющего web-интерфейса написана на языке JavaScript и распространяется под лицензией Apache 2.0... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56435
Ответить \| Правка \| Cообщить модератору

Оглавление

Почему во всех эти поделках всегда такая ощутимая задержка Причём, даже не в од, Аноним (1), 14:28 , 30-Дек-21, (1) +5

Меньше всего тормозит xpra и проброс хсервера Более менее юзабелен vnc и spice , пок (?), 14:40 , 30-Дек-21, (8) +1

Уху, правда текущий срез xpra сломан Но Antoine хорошо чинит, а я ему помогаю, Хру (?), 14:56 , 30-Дек-21, (14) +4
И да, я для CAD-ов даже на планшете еще в 13м году пользовал Splashtop Enterpris, Хру (?), 15:02 , 30-Дек-21, (15) –1
Написано что есть moonlight-qt и в релизах есть AppImage для линукса, почему ска, Аноним (17), 15:27 , 30-Дек-21, (17)

Потому что это клиенты, Массоны Рептилоиды (?), 17:48 , 30-Дек-21, (36) +1
Клиент в линуксах отлично работает, но хост пиписитарный только от нвидии под ви, пок (?), 22:36 , 30-Дек-21, (50) –1

VNC 8212 юзабелен Да это шутка дня просто , Аноним (18), 15:37 , 30-Дек-21, (18) –1
vnc придуман 150 лет назад , Урри (ok), 15:43 , 30-Дек-21, (20)

А покажите реальный годный пример хорошего воплощения этого vnc в реальных боевы, Константавр (ok), 17:29 , 30-Дек-21, (34) –1

да вот жеvncviewer 62 109 24 208https www opennet ru opennews art shtml num 55, test (??), 05:48 , 31-Дек-21, (67)
С CAD-ом, похоже все зависит от самого CAD-приложения Для виндовых ZWCAD, Bricas, ВыньОпух (ok), 15:15 , 31-Дек-21, (78) –1
nomachine же, belomir (?), 06:31 , 03-Янв-22, (99)

И что с того Нет привкуса смузи , Аноним (74), 11:55 , 31-Дек-21, (74)

Есть sunshine, bbb (??), 20:52 , 30-Дек-21, (45)

Поделитесь, пожалуйста, ссылкой Без этого ничего подобноно найти не удаётся, Михаил (??), 17:55 , 31-Дек-21, (82) –1

Пожалуйстаhttps github com loki-47-6F-64 sunshine, bbb (??), 21:12 , 31-Дек-21, (85)

Поддерживаю Разворачивал сервера с разными реализациями и заметил что на лине по, Илья (??), 14:42 , 30-Дек-21, (12)

связано с тем что на rdp в линкусе всем плевать и делаю подделки на костылях , анонисик (?), 16:17 , 30-Дек-21, (26) +3
С тем, что Windows изначально заточен на работу с графикой приложение Win32 пол, funny.falcon (?), 20:04 , 30-Дек-21, (43) +4

Ах, как было бы прекрасно, еслиб это было правдой на 100 Увы но нет, точнее , pofigist (?), 08:39 , 31-Дек-21, (68) –1

Я по долгу службы много имел дело с разными терминальными решениями и по запросу, Аноним (69), 10:37 , 31-Дек-21, (69)
продолжение 1 сессионный терминал не может работать с SQL-,fpfvb- Никакие фоновы, Аноним (69), 10:46 , 31-Дек-21, (70) –1
Продолжение 2 кодеки Все эти векторные кодеки совершенно не актуальны в услов, Аноним (69), 11:10 , 31-Дек-21, (72) –1

Я в курсе В ТЕОРИИ - можно сделать рабочий стол на чистых WinForms или иксах, п, pofigist (?), 16:05 , 31-Дек-21, (81) –1

Продолжение 3 RDMARDMA позволяет расшарить буфер, который объявлен в оперативной, Аноним (69), 11:41 , 31-Дек-21, (73) –1

Спасибо за подробную лекцию, но я знаю что такое RDMA, как оно работает и откуда, pofigist (?), 15:58 , 31-Дек-21, (80) –2

Я серьезно так думаю, потому что теории в п 1,2,3 вами предполагается решение , Аноним (69), 18:33 , 31-Дек-21, (84)

rdp и vnc протоколы разного уровня vnc тупо гоняет экран образно говоря, целик, Аноним (52), 23:14 , 30-Дек-21, (52) +2

это шутка дня просто покажите исходники хоть одной реализации RDP где это реали, test (??), 08:06 , 01-Янв-22, (91) –2

Кто-то тестил сабж Задержка есть Пользоваться удобно Так -то вещь удобная для, Аноним (32), 17:02 , 30-Дек-21, (32)

Из сабжа гонял xRDP На разных машинах с разными DE результат разный С Mate - но, ВыньОпух (ok), 15:19 , 31-Дек-21, (79) –1

Я раньше кучу всего перепробовал И пришёл к выводу что на линуксе лучшую реализ, Анонус (?), 11:07 , 31-Дек-21, (71) +1

Погодите, а раньше что - так нельзя было RDP, проброс иксовых сессий Не поль, InuYasha (??), 14:28 , 30-Дек-21, (2) +5

Когда пользователей больше одного - замучаешься настраивать, кому какие приложен, Аноним (5), 14:33 , 30-Дек-21, (5) +1

Вот и выросло поколение 8230 , Аноним (74), 12:01 , 31-Дек-21, (75) +2

Раньше это называлось LTE Т е стартовал gdm на машине, монтировал по nfs файлов, test (??), 14:40 , 30-Дек-21, (7) +3

https ru wikipedia org wiki LTSP, test (??), 14:41 , 30-Дек-21, (10) +2

они переименовались помню LTSM есть какой то на github, test (??), 05:37 , 31-Дек-21, (64) –1

Раньше было сложно сейчас все просто с новым смузидистрибутивчиком , Аноним (18), 15:38 , 30-Дек-21, (19) –2

раньше ещё в школе русский язык учили, Аноним (30), 16:51 , 30-Дек-21, (30) +3

а ты прагилифал , Аноним (-), 16:52 , 30-Дек-21, (31) –1

Зачем что-то делать просто если можно сделать сложно Ну вот , Урри (ok), 15:52 , 30-Дек-21, (21)
-, Урри (ok), 15:52 , 30-Дек-21, (22)
RDP неплох, но, сколько ни пробовал, всё равно по Интернету заметно тормозит - в, burjui (ok), 22:54 , 30-Дек-21, (51)

Попробуйте NoMachine Если не коммерческое использование то вполне прилично рабо, OpenEcho (?), 03:29 , 31-Дек-21, (61) +2

Более того, NX - единственный позволяет подключаться к уже запущенным Х-сессиям , Анон ессно (?), 18:33 , 02-Янв-22, (97)

xrdp может xrdp inifork false , OpenEcho (?), 19:46 , 02-Янв-22, (98) +1

все что завязано на freerdp это обычный сжатый растр намного хуже чем норм zrle, test (??), 05:38 , 31-Дек-21, (65)

А что там с передачей русских текстов через буфер обмена VNC Таки исправили И к, VNC Docker containers (?), 21:54 , 31-Дек-21, (86) –1

таки исправил кто и где как это применить к тигервнс обратитесь к тупым разраба, test (??), 08:01 , 01-Янв-22, (89) –1
в стандарте RFB есть copypaste проблема клиент серверной реализации ваша пробле, test (??), 08:02 , 01-Янв-22, (90) –1

Дистр для браузера ещё не создали А дистр для прослушивания музыки или просмотр, Аноним (4), 14:31 , 30-Дек-21, (4) –8

128405 , пок (?), 14:42 , 30-Дек-21, (11) –1
Chrome OS, Аноним (13), 14:43 , 30-Дек-21, (13) +18

почему бы просто не использовать версию 1 0 и всем бы стало понятно , zloykakpes (ok), 14:39 , 30-Дек-21, (6) +1

Авторы как бы намекают на уровень стабильности , Аноним (16), 15:02 , 30-Дек-21, (16) +7

В SemVer не значит чем больше цифра, тем стабильнее Удивлен твоему количеству, Самокатофил (?), 18:59 , 30-Дек-21, (38) +1

Ты слишком хорошего мнения о местной публике , Аноним (1), 20:34 , 30-Дек-21, (44) +1
Удивлён твоему удивлению Там не больше цифра , там первый не ноль , Captain (??), 21:05 , 30-Дек-21, (47) –3

для лл , Аноним (30), 14:41 , 30-Дек-21, (9) –3
ssh -X намного лучше всяких захватов экрана целиком , EuPhobos (ok), 16:01 , 30-Дек-21, (23) –2

Не по глобальной сети, mikhailnov (ok), 16:11 , 30-Дек-21, (24) +1
ага, только в миллиард раз медленнее даже по локалке, Аноним (30), 16:47 , 30-Дек-21, (28) –1

Как-то требовалось контролировать работу IPTV на узле провайдера, имитируя абоне, Аноним (25), 16:14 , 30-Дек-21, (25) +4

Теперь понятно откуда у таких прывайдеров затыки в трансляциях , Хру (?), 17:09 , 30-Дек-21, (33)
Я уж думал никто и не впомнит про NoMachine, работает то он классно и на венде м, OpenEcho (?), 00:06 , 31-Дек-21, (53) +1

и почему rdp чем это лучше остальных vnc etc ПО если не рассматривать через при, Аноним (27), 16:34 , 30-Дек-21, (27)

если ты не знаешь, чем rdp лучше vnc, тебе стоит подучить матчасть, Аноним (30), 16:49 , 30-Дек-21, (29) +4

Разумный админ корпоративной ИТ-инфраструктуры этого не допустит , Аноним (35), 17:47 , 30-Дек-21, (35) –2

На рабочем месте не нужен браузер с интернетом И от чего тогда спасает подключен, Аноним (41), 19:59 , 30-Дек-21, (41) +1

Прививку не ставят , а делают Ставят клизму и капельницу , Аноним (48), 21:47 , 30-Дек-21, (48)
Таки да, в 90 интернет на _рабочем_ месте не нужен А если и невозможно в остав, Криптоханыга (?), 19:25 , 01-Янв-22, (93)

Ды конечно Пользуюсь этим XRDP - у него соединение падает постоянно, особенно п, Аноним (37), 18:01 , 30-Дек-21, (37) –2

Вы просто не умете его варить сам по себе xrdp не отваливается, это либо система, OpenEcho (?), 00:20 , 31-Дек-21, (55) +1

А когда оно научится переключать раскладки в форме авторизации, позвольте спроси, Криптоханыга (?), 19:26 , 01-Янв-22, (94) –1

Понятия не имею Такие вопросы думаю уместны здесь https github com neutrinola, OpenEcho (?), 16:02 , 02-Янв-22, (96)

А как на счет звука почему никто не говорит, есть стабильная двухстороняя трансл, Аноним (39), 19:03 , 30-Дек-21, (39) –1

может зависеть от наличия отсутствия драйверов, их качества, а также поддержки a, zz (??), 20:02 , 30-Дек-21, (42) +2

И интерфейс под мобильные пальцетыковые экраны Горите в аду , слонёнок (?), 19:53 , 30-Дек-21, (40) +3
А теперь https thinstation org нельзя использовать , Атон (?), 20:54 , 30-Дек-21, (46) –1
Как то пришлось NoMachine ползоваться Вот это качество Совершенно гладкая пере, Штунц (?), 22:23 , 30-Дек-21, (49)

И чем x2go хуже , x3who (?), 00:10 , 31-Дек-21, (54)

NoMachine - жмет поток аппаратно с h 264 потому и скорость и качество, a x2go юз, OpenEcho (?), 00:26 , 31-Дек-21, (56)

т е умеет жать там, где есть аппаратная поддержка сжатия Тысячи вебкамер их кл, x3who (?), 00:38 , 31-Дек-21, (59)

Я не пойму, это риторический вопрос или вы и правда не знаете, что большинство к, OpenEcho (?), 03:21 , 31-Дек-21, (60)

чем это вам поможет с чего вы решили что от терм сервера на клиент идет 264 , test (??), 05:30 , 31-Дек-21, (63) –1

Скорость друг, скорость И качествоhttps i imgur com 7gJW1HB png, OpenEcho (?), 18:01 , 31-Дек-21, (83) –2

те там на каждого клиента постоянно HD видео кодирует на терминальном сервере р, test (??), 07:57 , 01-Янв-22, (87)

для одного рабочего места нормально , test (??), 07:59 , 01-Янв-22, (88)
Не на клиенте, а на сервереРаботают программы, нормально Если б вы сталкивались, OpenEcho (?), 15:59 , 02-Янв-22, (95) –1

Лично у меня кодирование h 264 идет со скоростью 4-6 кадров секунду Комп не из , x3who (?), 12:25 , 04-Янв-22, (100)

Эээ, не скажу, не пользовался Возможно тоже хорошее, Штунц (?), 00:27 , 31-Дек-21, (57) –1

выше по треду хвалили, и в в принципе оно в локалке смоотрится так же в глобал, x3who (?), 00:32 , 31-Дек-21, (58) +1

Пихать в один TCP поток видео, звук и данные от принтера например это очень мед, test (??), 05:41 , 31-Дек-21, (66) –1
Не очень понятно, зачем весь десктоп тянуть, если работаем мы с приложениями, а , adolfus (ok), 17:13 , 01-Янв-22, (92) –1
Поставил этот Linux Remote Desktopкаждая новая сессия новый предустановленный , Ананас (?), 11:34 , 12-Авг-22, (101)

Сообщения [Сортировка по времени | RSS]

1. "Первый стабильный выпуск проекта Linux Remote Desktop" +5 +/–

Сообщение от Аноним (1), 30-Дек-21, 14:28

Почему во всех эти поделках всегда такая ощутимая задержка? Причём, даже не в одной локалочке, а на одном хосте. Я единственный, кто это наблюдает?

Ответить | Правка | Наверх | Cообщить модератору

8. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от пок (?), 30-Дек-21, 14:40

Меньше всего тормозит xpra и проброс хсервера. Более менее юзабелен vnc и spice.
Все остальное это страх и ужас.
В линуксах сильно нехватает аналога нвидийного https://moonlight-stream.org/
Это пока единственный способ расшарить десктоп из офиса домой и из дома в офис который даёт на 95% локальный экспириенс для использования CAD софта.

Ответить | Правка | Наверх | Cообщить модератору

14. "Первый стабильный выпуск проекта Linux Remote Desktop" +4 +/–

Сообщение от Хру (?), 30-Дек-21, 14:56

Уху, правда текущий срез xpra сломан :( Но Antoine хорошо чинит, а я ему помогаю )))

Ответить | Правка | Наверх | Cообщить модератору

15. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Хру (?), 30-Дек-21, 15:02

И да, я для CAD-ов даже на планшете еще в 13м году пользовал Splashtop Enterprise. Солид и катьку крутил на ура!

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

17. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (17), 30-Дек-21, 15:27

Написано что есть moonlight-qt и в релизах есть AppImage для линукса, почему сказали что не хватает? Я ни разу не пользовался этой технологией, интересно узнать что это и зачем.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

36. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от Массоны Рептилоиды (?), 30-Дек-21, 17:48

Потому что это клиенты

Ответить | Правка | Наверх | Cообщить модератору

50. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от пок (?), 30-Дек-21, 22:36

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

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

18. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (18), 30-Дек-21, 15:37

VNC — юзабелен. Да это шутка дня просто.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

20. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Урри (ok), 30-Дек-21, 15:43

> Это пока единственный способ расшарить десктоп из офиса домой и из дома в офис который даёт на 95% локальный экспириенс для использования CAD софта.
vnc придуман 150 лет назад.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

34. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Константавр (ok), 30-Дек-21, 17:29

А покажите реальный годный пример хорошего воплощения этого vnc в реальных боевых условиях? А то я за всю жизнь ни разу не видел такого. Или 8цветов палитра, или сиди смотри как перерисовывается слайдшоу и глюки. Работу в CAD я себе не представляю в таком виде. А если говорить ещё и о передаче звука, то он вообще, в принципе не пригоден.

Ответить | Правка | Наверх | Cообщить модератору

67. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от test (??), 31-Дек-21, 05:48

да вот же
vncviewer 62.109.24.208
https://www.opennet.dev/opennews/art.shtml?num=55401

Ответить | Правка | Наверх | Cообщить модератору

78. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от ВыньОпух (ok), 31-Дек-21, 15:15

С CAD-ом, похоже все зависит от самого CAD-приложения.
Для виндовых ZWCAD, BricasCAD и AutoCAD, вне зависимости от клиента и протокола BricsCAD тормозит сильнее, чем AutoCAD. ZWCAD практически не имеет задержек по RDP, но не видит лицензию, по VNC иногда бывают лаги с выделением.
Под Linux нативные BricaCAD не хочет работать нормально ни через перенос вывода X-оы, ни через VNC, ни через Spice. Дикие задержки перерисовывания выделения. При этом на этих же хостах QCAD и LibreCAD таких тормозов не имеют.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

99. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от belomir (?), 03-Янв-22, 06:31

nomachine же

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

74. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (74), 31-Дек-21, 11:55

И что с того? Нет привкуса смузи?

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

45. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от bbb (??), 30-Дек-21, 20:52

Есть sunshine

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

82. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Михаил (??), 31-Дек-21, 17:55

Поделитесь, пожалуйста, ссылкой. Без этого ничего подобноно найти не удаётся

Ответить | Правка | Наверх | Cообщить модератору

85. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от bbb (??), 31-Дек-21, 21:12

Пожалуйста
https://github.com/loki-47-6F-64/sunshine

Ответить | Правка | Наверх | Cообщить модератору

12. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Илья (??), 30-Дек-21, 14:42

Поддерживаю.
Разворачивал сервера с разными реализациями и заметил что на лине потребление трафика больше 10мб на пользователя. Если сервер развернуть на ms, то при тех же условиях нагрузка на сеть меньше 1мб. Так и не понял с чем связано.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

26. "Первый стабильный выпуск проекта Linux Remote Desktop" +3 +/–

Сообщение от анонисик (?), 30-Дек-21, 16:17

связано с тем что на rdp в линкусе всем плевать и делаю подделки на костылях?

Ответить | Правка | Наверх | Cообщить модератору

43. "Первый стабильный выпуск проекта Linux Remote Desktop" +4 +/–

Сообщение от funny.falcon (?), 30-Дек-21, 20:04

С тем, что Windows изначально заточен на работу с графикой: приложение Win32 получает запрос от операционки на перерисовку кусочка своего окошка, а не всего целиком. Соответственно, «родной» RDP гоняет по сети только эти кусочки.
А как сделали интеграцию rdp с X-server, не известно. Возможно, что все окно приложения на каждый чих гоняют.
VNC пытается это решать, если я правильно понимаю, сравнивая кадры экрана по квадратам и находя различия.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

68. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от pofigist (?), 31-Дек-21, 08:39

> приложение Win32 получает запрос от операционки на перерисовку кусочка своего окошка, а не всего целиком. Соответственно, «родной» RDP гоняет по сети только эти кусочки.
Ах, как было бы прекрасно, еслиб это было правдой на 100%... Увы но нет, точнее - не всегда у него получается. Чтоб в этом убедится - поставьте на десктоп картинку поболее, зайдите  туда по RDP и подвигайте любое окошко...
Это проблема *любого* удаленного графического терминала - как только попадается большой растр, он начинает нещадно тормозить. Собственно как я понимаю - есть три решения, все плохие:
1. Вообще не использовать растр - только вектор. Даже текстуры. Результат немного предсказуем, сами понимаете - тяжелое детство, квадратные игрушки... :) Промежуточный вариант - загрузить все необходимые текстуры до начала работы, что сами понимаете не совсем реально... :)
2. Обрабатывать всю графику на сервере, а на клиента - тупо гнать видеопоток. Даже для игр - плохо, рассинхронизация (лаг) между действиями юзера и их последствиями на экране - неизбежна. Ну и канал дико жрется.
3. 10GbE с его RDMA. Ключевое слово - RDMA. Еще никто не сделал, насколько я знаю и работать будет исключительно в локалке.

Ответить | Правка | Наверх | Cообщить модератору

69. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (69), 31-Дек-21, 10:37

Я по долгу службы много имел дело с разными терминальными решениями и по запросу выправлял работу этих серверов у разных компаний от мала до велика. Я поголовно вижу проблему с пониманием этих технологий. В России еще и с русскоязычной документацией плохо, а читать по-английски умеют не все, поэтому появляются всякие домыслы, вроде ваших трёх пунктов.
Во-первых, есть 2 задачи, которые решают терминальные сервера:
1. Доставка удаленного приложения до пользователя
2. Организация удалённого рабочего места для пользователя.
Эти задачи имеют разную природу. В первом случае системный администратор хочет унифицировать приложение и доставить его любому пользователю на любое устройство, даже то, которое аппаратно не поддерживает запуск бинарного файла (x86 на ARM самый частый вариант). Второе - это задача организации унифицированного рабочего места сотрудника с последующей подачей этого рабочего места на тонкий клиент, во внешний интернет на недоверенное устройство или вовсе на бездисковую станцию.
Технически в основе сессионного терминальника лежит не столько графическое API, сколько специфически затюненный под эту задачу планировщик процессов ядра ОС. Если вы пользовались терминальными службами Windows и разрабатывали под них, вы знаете что у Windows несколько планировщиков процессов. Например, при установке служб RDS происходит смена планировщика на специфическую реализацию Fair Use относительно сессий. Задачу которую решает терминальный сервер - разделить ресурсы одного сервера одновременно нескольким пользовательским сессиям так, чтобы один пользователь не повесил весь сервер. Современная реализация этого планировщика (Windows 10+) сцеплена с другими драйверами позволяет делить iops-ы на на диске и сеть.
А что если мы хотим выдать одному пользователю больше ресурсов чем второму? На сессионном терминальнике - ничего. А если у нас сессия пользователя содержит тонну фоновых процессов, части из которых нужен свой планировщик для быстрой работы? А ничего!
Я приведу примеры:
- Никакой

Ответить | Правка | Наверх | Cообщить модератору

70. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (69), 31-Дек-21, 10:46

продолжение 1:
сессионный терминал не может работать с SQL-,fpfvb
- Никакие фоновый процессы не могут быть задержаны по диску в рамках той же сессии в которой выполняется основное приложение.
Отсюда должно стать понятно, почему для современных удаленных рабочих столов применяется 2 планировщика.
Один который делит пользователей - инфраструктура фиртуализации
Второй который делит процессы.
Вся современная задача по удаленному рабочему месту целиком перешла на инфраструктуру виртуализации.
Вот вам самый частый признак некомпетентного сотрудника:
Развернуть сервер терминалов в форме виртуальной машины, сделать его для пары приложений, дать полную сессию. А потом у них это всё тупить начинает.
Если задача давать приложения - ставьте сессионный терминальник. Полные сессии - делайте виртуальные десктопы. Ресурсы +/- те же но вы избавлены от проблем с планировщиком процессов сессионного терминальника.
Далее подумайте, он кодирует видео на сессиях. Если у вас включен SMT - у вас будут лаги и задержки. Если у вас виртуальные рабочие столы, то их профили можно и нужно подтюнить под SMT для снижения задержки.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

72. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (69), 31-Дек-21, 11:10

Продолжение 2... кодеки.
Все эти векторные кодеки совершенно не актуальны в условиях композитных рабочих столов. Даже на Windows если ваше приложение не из времен XP с полным WinForms оно не будет нормально закодировано векторными кодеками, потому что оно отрисовано в буфер DirectX. Графическая подсистема Windows начиная с 8 ТОЛЬКО КОМПОЗИТНАЯ. У нее нету больше этой логики, её выпилили!
У вас есть буферы, данные из которых отрисовываются на поверхности... Ну вот с ними сейчас и работаем. Отслеживаем изменения растра и шлём по сети. Для этого используется кодек H264 специально затюненный под эту работу. Его также можно переложить аппаратно на видеокарту, если у вас физический сессионный терминальный сервер. Если у вас виртуальный сессионный терминальник - не морочьте голову с видеокартами.
Взрослых решений по сессионным терминальным серверам 2:
- Citrix Virtual Apps and Desktops (бывший XenApp и XenDesktop). Для его работы с GPU требуется XenServer.
- Microsoft RDS
По виртуальным десктопам их 3:
- Citrix Virtual Apps and Desktops (бывший XenApp и XenDesktop). Для его работы с GPU требуется XenServer.
- Microsoft RDS
- VMware Horizon
Они поддерживают свои оригинальные старые кодеки для некомпозитной работы, но современные - это H264. Для тех кому нужен HDR используют VP9 (Citrix) и H265 (Horizon)
Отсюда ваш пункт 1 умер много лет назад не актуален и забудьте вообще. Если нужно API возьмите и напишите REST API и перетащите приложение в браузер. Для полного десктопа в композитном режиме это вообще не возможно.
Ваш пункт 2 не учитывает того что в нормальных современных протоколах удаленного рабочего стола существуют дополонительные транспортные пересылки. Например, вебсокеты, SIP/RTP, и другие медиапротоколы пересылаются на клиент напрямую без двойной буферизации. Вендоры виртуальных рабочих столов расширяют и тюнят поддерживаемые протоколы в своих клиентах для такого проброса. Естественно, криво развернутое RDP это не умеет. Нужно его задрать до RDP 8+ на сервере или сразу покупать Citrix, потому что только он умеет всё и сразу.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

81. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от pofigist (?), 31-Дек-21, 16:05

> Все эти векторные кодеки совершенно не актуальны в условиях композитных рабочих столов. Даже на Windows
Я в курсе. В ТЕОРИИ - можно сделать рабочий стол на чистых WinForms или иксах, практически без использования растра... Но это - только в теории. На практике - это будет возврат во времена twm
> Отсюда ваш пункт 1 умер много лет назад не актуален и забудьте вообще.
Я в курсе - привел ради истории :)

Ответить | Правка | Наверх | Cообщить модератору

73. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (69), 31-Дек-21, 11:41

Продолжение 3 RDMA
> 3. 10GbE с его RDMA. Ключевое слово - RDMA. Еще никто не сделал, насколько я знаю и работать будет исключительно в локалке.
RDMA позволяет расшарить буфер, который объявлен в оперативной памяти таким способом, чтобы обменом данных занимался не процессор, а чип сетевой карты. Для этого есть 2 протокола iWARP (на базе TCP) и RoCE (на базе UDP), который стандартизируют Control Plane на сети для RDMA.
RDMA не уменьшает задержку при помощи какой-то магии, оно её уменьшает посредством переноса нагрузки с процессоров и сопроцессоров на сетевую карту. И вот вам гетзефактс про RDMA:
1. RDMA требует QoS и lossless-очереди на коммутаторе.
Осознайте сложность этой задачи, пожалуйста... Задержка происходит от потерь/перезапросов данных из буфера. Для RoCE требуется ETS, PFC и DCBX расширения настроенные на коммутаторе. Если у вас RoCEv2, который решает тонну проблем первой версии связаной с PFC и Pause-фреймами Ethernet внутри VLAN, то у вас... Access порты с DSCP. Вы вообще понимаете сколько компаний готовы в датацентре поднять полноценный DSCP с доменом и квалификаторами? Далее проблема iWARP, который работает из коробки... но плохо. Для того чтобы iWARP приблизился по уровню задержек до RoCE нужно... настроить ему тот же самый QoS (DCBX,ETS,PFC). А QoS он распространяется на всю инфраструктуру и никогда не выходит за рамки собственной сети. Вашу маркировку кроме вас никто не примет.
2. RDMA хочет Jumbo
Если у вас lossless-сеть на базе RDMA минимальный размер MTU 9014. Причем протоколы вроде RDP прекрасно работают в таких сетях и снижают задержки... вот только как вы это передадите в интернет. Технически вы можете нарушить эту рекомендацию и снизиться до 4014, но смысла в 1500 у вас нету.
Для того чтобы дальше снизить задержку вам нужно выбросить Ethernet и поставить уже наконец-то Infiniband. RDMA родом из мира Infiniband.
Проблема усугубляется тем, что если ваш буфер находится на видеокарте, то вы будете сетевые карты подбирать под видеокарты, когда вы запретесь в одном вендоре целиком, то вам и сеть будет не так важна.
То что реально работает:
1. Nvidia Tesla/RTX + Nvidia Mellanox (сетевки и свитчи Infiniband)
2. Nvidia Tesla/RTX + Ethernet-сетевки Nvidia Mellanox + коммутаторы Juniper серии QFX
Я всё это пишу к тому, что это всё уже существует. RDMA настраивается на сети. Вы можете объявить новую сеть на своем коммутаторе, настроить QoS под RDMA. Nvidia уже имеет решения для такого стриминга через RDMA. Вы просто о них не знаете, потому что цена этих решений отобьёт у вас даже желание о них читать.
Вы правы только в том, что всё это работает только в рамках локальной сети, но для совсем удалёньщиков вы все равно обязаны поставить шлюз/балансировщик/прокси-сервер или чем вы там доставляете поток наружу...

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

80. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от pofigist (?), 31-Дек-21, 15:58

Спасибо за подробную лекцию, но я знаю что такое RDMA, как оно работает и откуда оно родом. :)
> Вы просто о них не знаете, потому что цена этих решений отобьёт у вас даже желание о них читать.
Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "CAD-решение на VDI, на блейдах разумеется, на не одну сотню рыл." По сравнению со стоимостью TeamCenter+NX - копейки :)
> Я всё это пишу к тому, что это всё уже существует. RDMA настраивается на сети.
Да-да, начиная с 10GbE - штатно.

Ответить | Правка | Наверх | Cообщить модератору

84. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (69), 31-Дек-21, 18:33

> Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "CAD-решение на VDI, на блейдах разумеется, на не одну сотню рыл." По сравнению со стоимостью TeamCenter+NX - копейки :)
Я серьезно так думаю, потому что теории в п. 1,2,3 вами предполагается "решение" вопросов затупа, задержек итд., которое не соответствует реальности.
В реальности то подмножество приложений, которым не нужна графика, но нужна доставка проще переписать, на веб-формы с REST API, чем городить терминальное решение, если количество пользователей выше 200 сотрудников. И так уже давно.
Растровые и 3D приложения требуют корректного развертывания. Современный VDI тюнится только под видео-вариант. Все пиринговые сети переносятся на тонкого клиента, по мере возможности в то время как приложения продолжают рисоваться на серверной стороне. Большинство приложений прекрасно вытерпят лаг в 40 мс round trip time. Дальше лаг зависит от сети. Нужно бороться с перегрузкой и джиттером.
Вы же понимаете что весь этот лаг берётся на коммутаторах и надо выяснять почему он возникает, правда же?
То что под VDI вам нужно реализовать Diffserv Assured Forwarding? И то что вам нужно разговаривать с провайдерами о проблемах на внешних отрезках сети?
> Да-да, начиная с 10GbE - штатно.
Хммм... не понимаете. Что такое "штатное RDMA"? Их 2 протокола, которые не совместимы друг с другом от разных вендоров. Наличие 10GbE порта не даёт вам возможность делать оффлоадинг CPU, нужна поддержка конкретного протокола и в вашем кластере в рамках проекта он у вас может быть только 1. Есть сетевки с обоими протоколами, а есть вообще не поддерживающие RDMA.
И с коммутаторами проблема... наличие возможности его применять на сетевке не даёт вам рабочее решение. У вас либо потери на сети, во время перегрузки (RoCEv2) или чудовищные провалы по задержкам (iWARP) вы либо заплели себе косы на коммутаторе под это, либо они у вас ничего не делают, или делают хуже. А коммутатор должен уметь это всё. Или может поддержка RDMA на коммутаторах у вас там штатная? Ха-ха-ха. Опыт с RDMA вне барахла от Intel был? Как деплоить знаем? А если знаем, чего так тупим?
Далее, выгода RDMA заметна там, где есть перегрузка по CPU. Оно даже с QoS-ами вам не сделает магически низкую задержку. А вот избавление от Ethernet в сторону IB улучшит... в рамках IB-сети.
Вы уже сейчас можете написать свое приложение которое пользуется RDMA поверх losless-фабрики, поможет ли вам это или нет зависит от сетевой топологии. Есть уже готовые решения от nvidia по вопросы применения RDMA в кластерах с их картами для машинного обучения и там цена как раз сравнима со стоимостью отраслевых решений.
Ну и самое главное... что вы собрались делать с Pause-фреймами в офисной/кампус сети?
RDMA применяется для важных данных, в частности для стораджей. Как работает Ethernet PFC, и что вы будете делать в офисной сети с портами на паузе? Про MTU я уже писал.
Вывод наличие RDMA именно на передаче буферов по терминальным соединениям не применимо даже в локальной сети. Только в рамках кластера виртуализации/терминалов. Не понятно только что там этот кластер тогда делает... зачем он сам себе свои приложения показывает... Ну на шлюзы свои во внешку разве что передаёт.

Ответить | Правка | Наверх | Cообщить модератору

52. "Первый стабильный выпуск проекта Linux Remote Desktop" +2 +/–

Сообщение от Аноним (52), 30-Дек-21, 23:14

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

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

91. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от test (??), 01-Янв-22, 08:06

это шутка дня просто! покажите исходники хоть одной реализации RDP где это реализовано?
все что я смотрел сам там обычно растр сжатый, как и во всех реализациях VNC где реализованы намного эффективнее алгоритмы.

Ответить | Правка | Наверх | Cообщить модератору

32. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (32), 30-Дек-21, 17:02

Кто-то тестил сабж? Задержка есть? Пользоваться удобно? Так -то вещь удобная для своей цели

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

79. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от ВыньОпух (ok), 31-Дек-21, 15:19

Из сабжа гонял xRDP. На разных машинах с разными DE результат разный.
С Mate - нормально, но не на офисном процессоре. С Fly нормально и на целероне работает.Но Fly еще найти надо, если не пользоваться Астрой.
В ряд ли в контейнере ситуация кардинально изменится.

Ответить | Правка | Наверх | Cообщить модератору

71. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от Анонус (?), 31-Дек-21, 11:07

Я раньше кучу всего перепробовал. И пришёл к выводу что на линуксе лучшую реализацию удалённого стола, сделала valve. Steam remote play, у меня работал с минимальной задержкой, при этом умеет в звук.
Единственное, для корпоративных целей, это скорее геморрой, но в отличии от TeamViewer, меня ни разу не подводил, когда нужно было показывать тяжёлые проекты.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Первый стабильный выпуск проекта Linux Remote Desktop" +5 +/–

Сообщение от InuYasha (??), 30-Дек-21, 14:28

Погодите, а раньше что - так нельзя было? RDP, проброс иксовых сессий..? Не пользовался. но слышал.
докеры-шмокеры...

Ответить | Правка | Наверх | Cообщить модератору

5. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от Аноним (5), 30-Дек-21, 14:33

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

Ответить | Правка | Наверх | Cообщить модератору

75. "Первый стабильный выпуск проекта Linux Remote Desktop" +2 +/–

Сообщение от Аноним (74), 31-Дек-21, 12:01

> Когда пользователей больше одного - замучаешься настраивать
Вот и выросло поколение…

Ответить | Правка | Наверх | Cообщить модератору

7. "Первый стабильный выпуск проекта Linux Remote Desktop" +3 +/–

Сообщение от test (??), 30-Дек-21, 14:40

Раньше это называлось LTE.
Т.е. стартовал gdm на машине, монтировал по nfs файловую систему сервера, и запускал Х11 сервер у себя на клиенте. Проги работали на сервере с Х11 клиентом.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

10. "Первый стабильный выпуск проекта Linux Remote Desktop" +2 +/–

Сообщение от test (??), 30-Дек-21, 14:41

https://ru.wikipedia.org/wiki/LTSP

Ответить | Правка | Наверх | Cообщить модератору

64. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от test (??), 31-Дек-21, 05:37

они переименовались?
помню LTSM есть какой то на github

Ответить | Правка | Наверх | Cообщить модератору

19. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от Аноним (18), 30-Дек-21, 15:38

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

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

30. "Первый стабильный выпуск проекта Linux Remote Desktop" +3 +/–

Сообщение от Аноним (30), 30-Дек-21, 16:51

раньше ещё в школе русский язык учили

Ответить | Правка | Наверх | Cообщить модератору

31. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (-), 30-Дек-21, 16:52

а ты прагилифал ?

Ответить | Правка | Наверх | Cообщить модератору

21. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Урри (ok), 30-Дек-21, 15:52

Зачем что-то делать просто если можно сделать сложно?
Ну вот.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

22. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Урри (ok), 30-Дек-21, 15:52

-

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

51. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от burjui (ok), 30-Дек-21, 22:54

RDP неплох, но, сколько ни пробовал, всё равно по Интернету заметно тормозит - во всяком случае, в Linux (к Windows подключаться не пытался). Проброс X по ssh - вообще за гранью. Пока что лучшее, что довелось испытать - X2Go, через него более-менее комфортно работать.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

61. "Первый стабильный выпуск проекта Linux Remote Desktop" +2 +/–

Сообщение от OpenEcho (?), 31-Дек-21, 03:29

Попробуйте NoMachine. Если не коммерческое использование то вполне прилично работает, а x2go кстати использует старый протокол NX от NoMachine

Ответить | Правка | Наверх | Cообщить модератору

97. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Анон ессно (?), 02-Янв-22, 18:33

Более того, NX - единственный позволяет подключаться к уже запущенным Х-сессиям ЕМНИП.

Ответить | Правка | Наверх | Cообщить модератору

98. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от OpenEcho (?), 02-Янв-22, 19:46

> Более того, NX - единственный позволяет подключаться к уже запущенным Х-сессиям ЕМНИП.
xrdp может:

```xrdp.ini
fork=false
```

Ответить | Правка | Наверх | Cообщить модератору

65. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от test (??), 31-Дек-21, 05:38

все что завязано на freerdp это обычный сжатый растр. намного хуже чем норм zrle от vnc.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

86. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от VNC Docker containers (?), 31-Дек-21, 21:54

А что там с передачей русских текстов через буфер обмена VNC?
Таки исправили? И как это применить к тому же TigerVNC к примеру?

Ответить | Правка | Наверх | Cообщить модератору

89. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от test (??), 01-Янв-22, 08:01

таки исправил кто и где? как это применить к тигервнс обратитесь к тупым разрабам тигервнс же

Ответить | Правка | Наверх | Cообщить модератору

90. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от test (??), 01-Янв-22, 08:02

в стандарте RFB есть copypaste проблема клиент серверной реализации  ваша проблема а не наша!

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

4. "Первый стабильный выпуск проекта Linux Remote Desktop" –8 +/–

Сообщение от Аноним (4), 30-Дек-21, 14:31

Дистр для браузера ещё не создали? А дистр для прослушивания музыки или просмотра фотографий? А может дистр для калькулятора уже существует? 🤔😆

Ответить | Правка | Наверх | Cообщить модератору

11. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от пок (?), 30-Дек-21, 14:42

🖕

Ответить | Правка | Наверх | Cообщить модератору

13. "Первый стабильный выпуск проекта Linux Remote Desktop" +18 +/–

Сообщение от Аноним (13), 30-Дек-21, 14:43

>Дистр для браузера
Chrome OS

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от zloykakpes (ok), 30-Дек-21, 14:39

> первый стабильный
> 0.9
почему бы просто не использовать версию 1.0 и всем бы стало понятно?

Ответить | Правка | Наверх | Cообщить модератору

16. "Первый стабильный выпуск проекта Linux Remote Desktop" +7 +/–

Сообщение от Аноним (16), 30-Дек-21, 15:02

Авторы как бы намекают на уровень стабильности.

Ответить | Правка | Наверх | Cообщить модератору

38. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от Самокатофил (?), 30-Дек-21, 18:59

В SemVer не значит "чем больше цифра, тем стабильнее". Удивлен твоему количеству плюсов.

Ответить | Правка | Наверх | Cообщить модератору

44. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от Аноним (1), 30-Дек-21, 20:34

Ты слишком хорошего мнения о местной публике.

Ответить | Правка | Наверх | Cообщить модератору

47. "Первый стабильный выпуск проекта Linux Remote Desktop" –3 +/–

Сообщение от Captain (??), 30-Дек-21, 21:05

Удивлён твоему удивлению!
Там не "больше цифра", там первый *не ноль*.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

9. "Первый стабильный выпуск проекта Linux Remote Desktop" –3 +/–

Сообщение от Аноним (30), 30-Дек-21, 14:41

для лл:
> Реализация управляющего web-интерфейса написана на языке JavaScript
> Проектом предлагается готовый docker-контейнер
> RDP

Ответить | Правка | Наверх | Cообщить модератору

23. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от EuPhobos (ok), 30-Дек-21, 16:01

"ssh -X" намного лучше всяких захватов экрана целиком.

Ответить | Правка | Наверх | Cообщить модератору

24. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от mikhailnov (ok), 30-Дек-21, 16:11

Не по глобальной сети

Ответить | Правка | Наверх | Cообщить модератору

28. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (30), 30-Дек-21, 16:47

ага, только в миллиард раз медленнее даже по локалке

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

25. "Первый стабильный выпуск проекта Linux Remote Desktop" +4 +/–

Сообщение от Аноним (25), 30-Дек-21, 16:14

Как-то требовалось контролировать работу IPTV на узле провайдера, имитируя абонента ШПД. Клиент был  в виде виртуальной машины в ЦОД провайдера. Единственный нормально рабочий вариант, который устроил - NoMachine. Адаптация под полосу пропускания работает на 5, комфортно смотреть видео с удалённого сайта как с фиксированного, так и с мобильного доступа, одинакого, что на десктоп, что на Android телефоне/планшете. Бесплатно только однопользовательский клиент/сервер. В Enterprise версии уже многопользовательский доступ есть. А VNC/SPICE/RDP в данном кейсе - слайдшоу.

Ответить | Правка | Наверх | Cообщить модератору

33. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Хру (?), 30-Дек-21, 17:09

Теперь понятно откуда у таких "прывайдеров" затыки в трансляциях!

Ответить | Правка | Наверх | Cообщить модератору

53. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от OpenEcho (?), 31-Дек-21, 00:06

Я уж думал никто и не впомнит про NoMachine, работает то он классно и на венде можно поставить и на хоум версию и на лине тоже работает очень прилично, вполне можно смотреть видео, неговоря уже про шустый отзыв, единственный минус - лицензия, которая только для дома, а если брать под бизнес, то цены очень близко к teamviewer подбираются

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

27. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (27), 30-Дек-21, 16:34

и почему rdp?
чем это лучше остальных vnc/etc ПО?
если не рассматривать через призму сотен виндоклиентов rdp на винде

Ответить | Правка | Наверх | Cообщить модератору

29. "Первый стабильный выпуск проекта Linux Remote Desktop" +4 +/–

Сообщение от Аноним (30), 30-Дек-21, 16:49

если ты не знаешь, чем rdp лучше vnc, тебе стоит подучить матчасть

Ответить | Правка | Наверх | Cообщить модератору

35. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от Аноним (35), 30-Дек-21, 17:47

>работа без использования VPN.
Разумный админ корпоративной ИТ-инфраструктуры этого не допустит.

Ответить | Правка | Наверх | Cообщить модератору

41. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от Аноним (41), 30-Дек-21, 19:59

На рабочем месте не нужен браузер с интернетом?
И от чего тогда спасает подключение клиента по vpn?
У тебя юзер играет в русскую рулетку, но пусть наденет респиратор и поставит прививку.

Ответить | Правка | Наверх | Cообщить модератору

48. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Аноним (48), 30-Дек-21, 21:47

Прививку не "ставят", а делают.
Ставят клизму и капельницу.

Ответить | Правка | Наверх | Cообщить модератору

93. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Криптоханыга (?), 01-Янв-22, 19:25

Таки да, в 90% интернет на _рабочем_ месте не нужен. А если и невозможно в оставщихся 10% случаев без него обойтись - ИБ всё равно заставят гонять траф через корпоративный Firewall с политиками безопасности, потоковым антивирусом и прочими энтерпрайсными плюшками. Иначе первый же "шифровальщик" поставит всю контору раком...

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

37. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от Аноним (37), 30-Дек-21, 18:01

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

Ответить | Правка | Наверх | Cообщить модератору

55. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от OpenEcho (?), 31-Дек-21, 00:20

> XRDP - у него соединение падает постоянно
Вы просто не умете его варить.
сам по себе xrdp не отваливается, это либо система скидывает, либо канал кака.
А скорость увеличить может простой твик
=== xrdp.ini ===
tcp_keepalive=true
# можно поиграться с
#tcp_send_buffer_bytes=32768
#tcp_recv_buffer_bytes=32768
# Потому как подключение либо через VPN непосредственно к хосту или SSH на 127.0.0.1, то нафиг оно не надо
crypt_level=none
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
# И самая гланая вишенка на тортик:
max_bpp=16
==============

Ответить | Правка | Наверх | Cообщить модератору

94. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Криптоханыга (?), 01-Янв-22, 19:26

А когда оно научится переключать раскладки в форме авторизации, позвольте спросить?

Ответить | Правка | Наверх | Cообщить модератору

96. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от OpenEcho (?), 02-Янв-22, 16:02

> А когда оно научится переключать раскладки в форме авторизации, позвольте спросить?
Понятия не имею.
Такие вопросы думаю уместны здесь: https://github.com/neutrinolabs/xrdp/issues

Ответить | Правка | Наверх | Cообщить модератору

39. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Аноним (39), 30-Дек-21, 19:03

А как на счет звука почему никто не говорит, есть стабильная двухстороняя трансляция или ее нет ?

Ответить | Правка | Наверх | Cообщить модератору

42. "Первый стабильный выпуск проекта Linux Remote Desktop" +2 +/–

Сообщение от zz (??), 30-Дек-21, 20:02

может зависеть от наличия\отсутствия драйверов, их качества, а также поддержки alsa\pulseaudio\pipewire в системе на стороне сервера и на стороне клиента.
Не знаю, как в xrdp, а в клиенте xfreerdp работает, но не везде и не всегда (c опцией /audio)
xfreerdp /f +clipboard /compression /u:user_name /v:xxx.xxx.xxx.xxx /t:xxx.xxx.xxx.xxx /audio

Ответить | Правка | Наверх | Cообщить модератору

40. "Первый стабильный выпуск проекта Linux Remote Desktop" +3 +/–

Сообщение от слонёнок (?), 30-Дек-21, 19:53

И интерфейс под мобильные пальцетыковые экраны.
Горите в аду.

Ответить | Правка | Наверх | Cообщить модератору

46. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Атон (?), 30-Дек-21, 20:54

А теперь https://thinstation.org/  нельзя использовать?

Ответить | Правка | Наверх | Cообщить модератору

49. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Штунц (?), 30-Дек-21, 22:23

Как то пришлось NoMachine ползоваться. Вот это качество! Совершенно гладкая передача экрана была.
А вот у них и терминальный сервер есть:
https://www.nomachine.com/ru/terminal-server

Ответить | Правка | Наверх | Cообщить модератору

54. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от x3who (?), 31-Дек-21, 00:10

> Как то пришлось NoMachine
И чем x2go хуже?

Ответить | Правка | Наверх | Cообщить модератору

56. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от OpenEcho (?), 31-Дек-21, 00:26

NoMachine - жмет поток аппаратно с h.264 потому и скорость и качество, a x2go юзает то самый модефицированный NX протокол, который разработали в NoMachine

Ответить | Правка | Наверх | Cообщить модератору

59. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от x3who (?), 31-Дек-21, 00:38

> NoMachine - жмет поток аппаратно с h.264 потому и скорость и качество,
> a x2go юзает то самый модефицированный NX протокол, который разработали в
> NoMachine
т.е. умеет жать там, где есть аппаратная поддержка сжатия? Тысячи вебкамер их клиенты?

Ответить | Правка | Наверх | Cообщить модератору

60. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от OpenEcho (?), 31-Дек-21, 03:21

> т.е. умеет жать там, где есть аппаратная поддержка сжатия?
Я не пойму, это риторический вопрос или вы и правда не знаете, что большинство компьютеров уже имееют на борту h.264 (даже недо-видео карты в составе ЦПУ на интелах имеют QuickSync начиная с 4-го поколения кажется)
> Тысячи вебкамер их клиенты?
Гхм... А что уже есть вебкамеры с полнозначным desktop environment, чтоб там можно было мышкой пошевелить что нибудь???

Ответить | Правка | Наверх | Cообщить модератору

63. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от test (??), 31-Дек-21, 05:30

> правда не знаете, что большинство компьютеров уже имееют на борту h.264
чем это вам поможет?! с чего вы решили что от терм сервера на клиент идет 264?

Ответить | Правка | Наверх | Cообщить модератору

83. "Первый стабильный выпуск проекта Linux Remote Desktop" –2 +/–

Сообщение от OpenEcho (?), 31-Дек-21, 18:01

> чем это вам поможет?!
Скорость друг, скорость ! И качество
> с чего вы решили что от терм сервера на клиент идет 264?
https://i.imgur.com/7gJW1HB.png

Ответить | Правка | Наверх | Cообщить модератору

87. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от test (??), 01-Янв-22, 07:57

те там на каждого клиента постоянно HD видео кодирует? на терминальном сервере работать может человек 20-30 в вашем варианте вообще программы работают?

Ответить | Правка | Наверх | Cообщить модератору

88. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от test (??), 01-Янв-22, 07:59

для одного рабочего места нормально!

Ответить | Правка | Наверх | Cообщить модератору

95. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от OpenEcho (?), 02-Янв-22, 15:59

> те там на каждого клиента постоянно HD видео кодирует?
Не на клиенте, а на сервере
> на терминальном сервере работать может человек 20-30 в вашем варианте вообще программы работают?
Работают программы, нормально. Если б вы сталкивались с blueiris, то обнаружили бы, что можно и больше чем 30

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

100. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от x3who (?), 04-Янв-22, 12:25

> Я не пойму, это риторический вопрос или вы и правда не знаете,
> что большинство компьютеров уже имееют на борту h.264 (даже недо-видео карты
> в составе ЦПУ на интелах имеют QuickSync начиная с 4-го поколения
> кажется)
Лично у меня кодирование h.264 идет со скоростью 4-6 кадров секунду. Комп не из большинства, очевидно.
> Гхм... А что уже есть вебкамеры с полнозначным desktop environment, чтоб там
> можно было мышкой пошевелить что нибудь???
Зато вот они умеют один поток кодировать в реальном времени и порой даже в h.265 (HEVC)

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

57. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от Штунц (?), 31-Дек-21, 00:27

Эээ, не скажу, не пользовался. Возможно тоже хорошее

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

58. "Первый стабильный выпуск проекта Linux Remote Desktop" +1 +/–

Сообщение от x3who (?), 31-Дек-21, 00:32

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

Ответить | Правка | Наверх | Cообщить модератору

66. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от test (??), 31-Дек-21, 05:41

Пихать в один! TCP поток видео, звук и данные от принтера например это очень медленно.
Чего ваш RDP и делает с успехом. При печати весь графоний встаёт колом!

Ответить | Правка | Наверх | Cообщить модератору

92. "Первый стабильный выпуск проекта Linux Remote Desktop" –1 +/–

Сообщение от adolfus (ok), 01-Янв-22, 17:13

Не очень понятно, зачем весь десктоп тянуть, если работаем мы с приложениями, а не на десктоп пялимся.
Я уже лет пятнадцать именно так из-дома, если нужно, программирую -- в одном терминале ssh -Y, в котором slickedit, в другом (третьем и более, если нужно) остальное, рабочая почта, например. Чувствую себя, как будто прямо на фабрике работаю.
С другой стороны, x-сессия в сети 10 Мбит/с тоже нормально работает. Разумеется, если все свистоперделки бессмысленные, вплоть до визуализации перемещения содержимого окна, отключить нахрен.

Ответить | Правка | Наверх | Cообщить модератору

101. "Первый стабильный выпуск проекта Linux Remote Desktop" +/–

Сообщение от Ананас (?), 12-Авг-22, 11:34

Поставил этот Linux Remote Desktop
каждая новая сессия = новый предустановленный докер образ + приложения подключенные через веб интерфейс
установка простейшая,
из плюсов - работает шустро, базовые вещи есть
из минусов - хромиум не заводится по неизвестным причинам, каждый раз слетают настройки до базовых из предустановленного докер-образа(локаль например, настройки в прокинутых приложениях)
вроде прикольно, но пока что подходит только для класса информатики, для работы пока не допилено

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Первый стабильный выпуск проекта Linux Remote Desktop"	+5 +/–
Сообщение от Аноним (1), 30-Дек-21, 14:28
Почему во всех эти поделках всегда такая ощутимая задержка? Причём, даже не в одной локалочке, а на одном хосте. Я единственный, кто это наблюдает?
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Первый стабильный выпуск проекта Linux Remote Desktop"	+1 +/–
	Сообщение от пок (?), 30-Дек-21, 14:40
	Меньше всего тормозит xpra и проброс хсервера. Более менее юзабелен vnc и spice. Все остальное это страх и ужас. В линуксах сильно нехватает аналога нвидийного https://moonlight-stream.org/ Это пока единственный способ расшарить десктоп из офиса домой и из дома в офис который даёт на 95% локальный экспириенс для использования CAD софта.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Первый стабильный выпуск проекта Linux Remote Desktop"	+4 +/–
	Сообщение от Хру (?), 30-Дек-21, 14:56
	Уху, правда текущий срез xpra сломан :( Но Antoine хорошо чинит, а я ему помогаю )))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Хру (?), 30-Дек-21, 15:02
	И да, я для CAD-ов даже на планшете еще в 13м году пользовал Splashtop Enterprise. Солид и катьку крутил на ура!
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	17. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от Аноним (17), 30-Дек-21, 15:27
	Написано что есть moonlight-qt и в релизах есть AppImage для линукса, почему сказали что не хватает? Я ни разу не пользовался этой технологией, интересно узнать что это и зачем.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	36. "Первый стабильный выпуск проекта Linux Remote Desktop"	+1 +/–
	Сообщение от Массоны Рептилоиды (?), 30-Дек-21, 17:48
	Потому что это клиенты
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от пок (?), 30-Дек-21, 22:36
	Клиент в линуксах отлично работает, но хост пиписитарный только от нвидии под виндой.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	18. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Аноним (18), 30-Дек-21, 15:37
	VNC — юзабелен. Да это шутка дня просто.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	20. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от Урри (ok), 30-Дек-21, 15:43
	> Это пока единственный способ расшарить десктоп из офиса домой и из дома в офис который даёт на 95% локальный экспириенс для использования CAD софта. vnc придуман 150 лет назад.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	34. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Константавр (ok), 30-Дек-21, 17:29
	А покажите реальный годный пример хорошего воплощения этого vnc в реальных боевых условиях? А то я за всю жизнь ни разу не видел такого. Или 8цветов палитра, или сиди смотри как перерисовывается слайдшоу и глюки. Работу в CAD я себе не представляю в таком виде. А если говорить ещё и о передаче звука, то он вообще, в принципе не пригоден.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от test (??), 31-Дек-21, 05:48
	да вот же vncviewer 62.109.24.208 https://www.opennet.dev/opennews/art.shtml?num=55401
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от ВыньОпух (ok), 31-Дек-21, 15:15
	С CAD-ом, похоже все зависит от самого CAD-приложения. Для виндовых ZWCAD, BricasCAD и AutoCAD, вне зависимости от клиента и протокола BricsCAD тормозит сильнее, чем AutoCAD. ZWCAD практически не имеет задержек по RDP, но не видит лицензию, по VNC иногда бывают лаги с выделением. Под Linux нативные BricaCAD не хочет работать нормально ни через перенос вывода X-оы, ни через VNC, ни через Spice. Дикие задержки перерисовывания выделения. При этом на этих же хостах QCAD и LibreCAD таких тормозов не имеют.
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	99. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от belomir (?), 03-Янв-22, 06:31
	nomachine же
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	74. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от Аноним (74), 31-Дек-21, 11:55
	И что с того? Нет привкуса смузи?
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	45. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от bbb (??), 30-Дек-21, 20:52
	Есть sunshine
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	82. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Михаил (??), 31-Дек-21, 17:55
	Поделитесь, пожалуйста, ссылкой. Без этого ничего подобноно найти не удаётся
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от bbb (??), 31-Дек-21, 21:12
	Пожалуйста https://github.com/loki-47-6F-64/sunshine
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от Илья (??), 30-Дек-21, 14:42
	Поддерживаю. Разворачивал сервера с разными реализациями и заметил что на лине потребление трафика больше 10мб на пользователя. Если сервер развернуть на ms, то при тех же условиях нагрузка на сеть меньше 1мб. Так и не понял с чем связано.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	26. "Первый стабильный выпуск проекта Linux Remote Desktop"	+3 +/–
	Сообщение от анонисик (?), 30-Дек-21, 16:17
	связано с тем что на rdp в линкусе всем плевать и делаю подделки на костылях?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Первый стабильный выпуск проекта Linux Remote Desktop"	+4 +/–
	Сообщение от funny.falcon (?), 30-Дек-21, 20:04
	С тем, что Windows изначально заточен на работу с графикой: приложение Win32 получает запрос от операционки на перерисовку кусочка своего окошка, а не всего целиком. Соответственно, «родной» RDP гоняет по сети только эти кусочки. А как сделали интеграцию rdp с X-server, не известно. Возможно, что все окно приложения на каждый чих гоняют. VNC пытается это решать, если я правильно понимаю, сравнивая кадры экрана по квадратам и находя различия.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	68. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от pofigist (?), 31-Дек-21, 08:39
	> приложение Win32 получает запрос от операционки на перерисовку кусочка своего окошка, а не всего целиком. Соответственно, «родной» RDP гоняет по сети только эти кусочки. Ах, как было бы прекрасно, еслиб это было правдой на 100%... Увы но нет, точнее - не всегда у него получается. Чтоб в этом убедится - поставьте на десктоп картинку поболее, зайдите туда по RDP и подвигайте любое окошко... Это проблема любого удаленного графического терминала - как только попадается большой растр, он начинает нещадно тормозить. Собственно как я понимаю - есть три решения, все плохие: 1. Вообще не использовать растр - только вектор. Даже текстуры. Результат немного предсказуем, сами понимаете - тяжелое детство, квадратные игрушки... :) Промежуточный вариант - загрузить все необходимые текстуры до начала работы, что сами понимаете не совсем реально... :) 2. Обрабатывать всю графику на сервере, а на клиента - тупо гнать видеопоток. Даже для игр - плохо, рассинхронизация (лаг) между действиями юзера и их последствиями на экране - неизбежна. Ну и канал дико жрется. 3. 10GbE с его RDMA. Ключевое слово - RDMA. Еще никто не сделал, насколько я знаю и работать будет исключительно в локалке.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от Аноним (69), 31-Дек-21, 10:37
	Я по долгу службы много имел дело с разными терминальными решениями и по запросу выправлял работу этих серверов у разных компаний от мала до велика. Я поголовно вижу проблему с пониманием этих технологий. В России еще и с русскоязычной документацией плохо, а читать по-английски умеют не все, поэтому появляются всякие домыслы, вроде ваших трёх пунктов. Во-первых, есть 2 задачи, которые решают терминальные сервера: 1. Доставка удаленного приложения до пользователя 2. Организация удалённого рабочего места для пользователя. Эти задачи имеют разную природу. В первом случае системный администратор хочет унифицировать приложение и доставить его любому пользователю на любое устройство, даже то, которое аппаратно не поддерживает запуск бинарного файла (x86 на ARM самый частый вариант). Второе - это задача организации унифицированного рабочего места сотрудника с последующей подачей этого рабочего места на тонкий клиент, во внешний интернет на недоверенное устройство или вовсе на бездисковую станцию. Технически в основе сессионного терминальника лежит не столько графическое API, сколько специфически затюненный под эту задачу планировщик процессов ядра ОС. Если вы пользовались терминальными службами Windows и разрабатывали под них, вы знаете что у Windows несколько планировщиков процессов. Например, при установке служб RDS происходит смена планировщика на специфическую реализацию Fair Use относительно сессий. Задачу которую решает терминальный сервер - разделить ресурсы одного сервера одновременно нескольким пользовательским сессиям так, чтобы один пользователь не повесил весь сервер. Современная реализация этого планировщика (Windows 10+) сцеплена с другими драйверами позволяет делить iops-ы на на диске и сеть. А что если мы хотим выдать одному пользователю больше ресурсов чем второму? На сессионном терминальнике - ничего. А если у нас сессия пользователя содержит тонну фоновых процессов, части из которых нужен свой планировщик для быстрой работы? А ничего! Я приведу примеры: - Никакой
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Аноним (69), 31-Дек-21, 10:46
	продолжение 1: сессионный терминал не может работать с SQL-,fpfvb - Никакие фоновый процессы не могут быть задержаны по диску в рамках той же сессии в которой выполняется основное приложение. Отсюда должно стать понятно, почему для современных удаленных рабочих столов применяется 2 планировщика. Один который делит пользователей - инфраструктура фиртуализации Второй который делит процессы. Вся современная задача по удаленному рабочему месту целиком перешла на инфраструктуру виртуализации. Вот вам самый частый признак некомпетентного сотрудника: Развернуть сервер терминалов в форме виртуальной машины, сделать его для пары приложений, дать полную сессию. А потом у них это всё тупить начинает. Если задача давать приложения - ставьте сессионный терминальник. Полные сессии - делайте виртуальные десктопы. Ресурсы +/- те же но вы избавлены от проблем с планировщиком процессов сессионного терминальника. Далее подумайте, он кодирует видео на сессиях. Если у вас включен SMT - у вас будут лаги и задержки. Если у вас виртуальные рабочие столы, то их профили можно и нужно подтюнить под SMT для снижения задержки.
	Ответить \| Правка \| К родителю #68 \| Наверх \| Cообщить модератору


	72. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Аноним (69), 31-Дек-21, 11:10
	Продолжение 2... кодеки. Все эти векторные кодеки совершенно не актуальны в условиях композитных рабочих столов. Даже на Windows если ваше приложение не из времен XP с полным WinForms оно не будет нормально закодировано векторными кодеками, потому что оно отрисовано в буфер DirectX. Графическая подсистема Windows начиная с 8 ТОЛЬКО КОМПОЗИТНАЯ. У нее нету больше этой логики, её выпилили! У вас есть буферы, данные из которых отрисовываются на поверхности... Ну вот с ними сейчас и работаем. Отслеживаем изменения растра и шлём по сети. Для этого используется кодек H264 специально затюненный под эту работу. Его также можно переложить аппаратно на видеокарту, если у вас физический сессионный терминальный сервер. Если у вас виртуальный сессионный терминальник - не морочьте голову с видеокартами. Взрослых решений по сессионным терминальным серверам 2: - Citrix Virtual Apps and Desktops (бывший XenApp и XenDesktop). Для его работы с GPU требуется XenServer. - Microsoft RDS По виртуальным десктопам их 3: - Citrix Virtual Apps and Desktops (бывший XenApp и XenDesktop). Для его работы с GPU требуется XenServer. - Microsoft RDS - VMware Horizon Они поддерживают свои оригинальные старые кодеки для некомпозитной работы, но современные - это H264. Для тех кому нужен HDR используют VP9 (Citrix) и H265 (Horizon) Отсюда ваш пункт 1 умер много лет назад не актуален и забудьте вообще. Если нужно API возьмите и напишите REST API и перетащите приложение в браузер. Для полного десктопа в композитном режиме это вообще не возможно. Ваш пункт 2 не учитывает того что в нормальных современных протоколах удаленного рабочего стола существуют дополонительные транспортные пересылки. Например, вебсокеты, SIP/RTP, и другие медиапротоколы пересылаются на клиент напрямую без двойной буферизации. Вендоры виртуальных рабочих столов расширяют и тюнят поддерживаемые протоколы в своих клиентах для такого проброса. Естественно, криво развернутое RDP это не умеет. Нужно его задрать до RDP 8+ на сервере или сразу покупать Citrix, потому что только он умеет всё и сразу.
	Ответить \| Правка \| К родителю #68 \| Наверх \| Cообщить модератору


	81. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от pofigist (?), 31-Дек-21, 16:05
	> Все эти векторные кодеки совершенно не актуальны в условиях композитных рабочих столов. Даже на Windows Я в курсе. В ТЕОРИИ - можно сделать рабочий стол на чистых WinForms или иксах, практически без использования растра... Но это - только в теории. На практике - это будет возврат во времена twm > Отсюда ваш пункт 1 умер много лет назад не актуален и забудьте вообще. Я в курсе - привел ради истории :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Первый стабильный выпуск проекта Linux Remote Desktop"	–1 +/–
	Сообщение от Аноним (69), 31-Дек-21, 11:41
	Продолжение 3 RDMA > 3. 10GbE с его RDMA. Ключевое слово - RDMA. Еще никто не сделал, насколько я знаю и работать будет исключительно в локалке. RDMA позволяет расшарить буфер, который объявлен в оперативной памяти таким способом, чтобы обменом данных занимался не процессор, а чип сетевой карты. Для этого есть 2 протокола iWARP (на базе TCP) и RoCE (на базе UDP), который стандартизируют Control Plane на сети для RDMA. RDMA не уменьшает задержку при помощи какой-то магии, оно её уменьшает посредством переноса нагрузки с процессоров и сопроцессоров на сетевую карту. И вот вам гетзефактс про RDMA: 1. RDMA требует QoS и lossless-очереди на коммутаторе. Осознайте сложность этой задачи, пожалуйста... Задержка происходит от потерь/перезапросов данных из буфера. Для RoCE требуется ETS, PFC и DCBX расширения настроенные на коммутаторе. Если у вас RoCEv2, который решает тонну проблем первой версии связаной с PFC и Pause-фреймами Ethernet внутри VLAN, то у вас... Access порты с DSCP. Вы вообще понимаете сколько компаний готовы в датацентре поднять полноценный DSCP с доменом и квалификаторами? Далее проблема iWARP, который работает из коробки... но плохо. Для того чтобы iWARP приблизился по уровню задержек до RoCE нужно... настроить ему тот же самый QoS (DCBX,ETS,PFC). А QoS он распространяется на всю инфраструктуру и никогда не выходит за рамки собственной сети. Вашу маркировку кроме вас никто не примет. 2. RDMA хочет Jumbo Если у вас lossless-сеть на базе RDMA минимальный размер MTU 9014. Причем протоколы вроде RDP прекрасно работают в таких сетях и снижают задержки... вот только как вы это передадите в интернет. Технически вы можете нарушить эту рекомендацию и снизиться до 4014, но смысла в 1500 у вас нету. Для того чтобы дальше снизить задержку вам нужно выбросить Ethernet и поставить уже наконец-то Infiniband. RDMA родом из мира Infiniband. Проблема усугубляется тем, что если ваш буфер находится на видеокарте, то вы будете сетевые карты подбирать под видеокарты, когда вы запретесь в одном вендоре целиком, то вам и сеть будет не так важна. То что реально работает: 1. Nvidia Tesla/RTX + Nvidia Mellanox (сетевки и свитчи Infiniband) 2. Nvidia Tesla/RTX + Ethernet-сетевки Nvidia Mellanox + коммутаторы Juniper серии QFX Я всё это пишу к тому, что это всё уже существует. RDMA настраивается на сети. Вы можете объявить новую сеть на своем коммутаторе, настроить QoS под RDMA. Nvidia уже имеет решения для такого стриминга через RDMA. Вы просто о них не знаете, потому что цена этих решений отобьёт у вас даже желание о них читать. Вы правы только в том, что всё это работает только в рамках локальной сети, но для совсем удалёньщиков вы все равно обязаны поставить шлюз/балансировщик/прокси-сервер или чем вы там доставляете поток наружу...
	Ответить \| Правка \| К родителю #68 \| Наверх \| Cообщить модератору


	80. "Первый стабильный выпуск проекта Linux Remote Desktop"	–2 +/–
	Сообщение от pofigist (?), 31-Дек-21, 15:58
	Спасибо за подробную лекцию, но я знаю что такое RDMA, как оно работает и откуда оно родом. :) > Вы просто о них не знаете, потому что цена этих решений отобьёт у вас даже желание о них читать. Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "CAD-решение на VDI, на блейдах разумеется, на не одну сотню рыл." По сравнению со стоимостью TeamCenter+NX - копейки :) > Я всё это пишу к тому, что это всё уже существует. RDMA настраивается на сети. Да-да, начиная с 10GbE - штатно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. "Первый стабильный выпуск проекта Linux Remote Desktop"	+/–
	Сообщение от Аноним (69), 31-Дек-21, 18:33
	> Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "CAD-решение на VDI, на блейдах разумеется, на не одну сотню рыл." По сравнению со стоимостью TeamCenter+NX - копейки :) Я серьезно так думаю, потому что теории в п. 1,2,3 вами предполагается "решение" вопросов затупа, задержек итд., которое не соответствует реальности. В реальности то подмножество приложений, которым не нужна графика, но нужна доставка проще переписать, на веб-формы с REST API, чем городить терминальное решение, если количество пользователей выше 200 сотрудников. И так уже давно. Растровые и 3D приложения требуют корректного развертывания. Современный VDI тюнится только под видео-вариант. Все пиринговые сети переносятся на тонкого клиента, по мере возможности в то время как приложения продолжают рисоваться на серверной стороне. Большинство приложений прекрасно вытерпят лаг в 40 мс round trip time. Дальше лаг зависит от сети. Нужно бороться с перегрузкой и джиттером. Вы же понимаете что весь этот лаг берётся на коммутаторах и надо выяснять почему он возникает, правда же? То что под VDI вам нужно реализовать Diffserv Assured Forwarding? И то что вам нужно разговаривать с провайдерами о проблемах на внешних отрезках сети? > Да-да, начиная с 10GbE - штатно. Хммм... не понимаете. Что такое "штатное RDMA"? Их 2 протокола, которые не совместимы друг с другом от разных вендоров. Наличие 10GbE порта не даёт вам возможность делать оффлоадинг CPU, нужна поддержка конкретного протокола и в вашем кластере в рамках проекта он у вас может быть только 1. Есть сетевки с обоими протоколами, а есть вообще не поддерживающие RDMA. И с коммутаторами проблема... наличие возможности его применять на сетевке не даёт вам рабочее решение. У вас либо потери на сети, во время перегрузки (RoCEv2) или чудовищные провалы по задержкам (iWARP) вы либо заплели себе косы на коммутаторе под это, либо они у вас ничего не делают, или делают хуже. А коммутатор должен уметь это всё. Или может поддержка RDMA на коммутаторах у вас там штатная? Ха-ха-ха. Опыт с RDMA вне барахла от Intel был? Как деплоить знаем? А если знаем, чего так тупим? Далее, выгода RDMA заметна там, где есть перегрузка по CPU. Оно даже с QoS-ами вам не сделает магически низкую задержку. А вот избавление от Ethernet в сторону IB улучшит... в рамках IB-сети. Вы уже сейчас можете написать свое приложение которое пользуется RDMA поверх losless-фабрики, поможет ли вам это или нет зависит от сетевой топологии. Есть уже готовые решения от nvidia по вопросы применения RDMA в кластерах с их картами для машинного обучения и там цена как раз сравнима со стоимостью отраслевых решений. Ну и самое главное... что вы собрались делать с Pause-фреймами в офисной/кампус сети? RDMA применяется для важных данных, в частности для стораджей. Как работает Ethernet PFC, и что вы будете делать в офисной сети с портами на паузе? Про MTU я уже писал. Вывод наличие RDMA именно на передаче буферов по терминальным соединениям не применимо даже в локальной сети. Только в рамках кластера виртуализации/терминалов. Не понятно только что там этот кластер тогда делает... зачем он сам себе свои приложения показывает... Ну на шлюзы свои во внешку разве что передаёт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Первый стабильный выпуск проекта Linux Remote Desktop"	+2 +/–
	Сообщение от Аноним (52), 30-Дек-21, 23:14
	rdp и vnc протоколы разного уровня. vnc тупо гоняет экран (образно говоря, целиком растровое изображение). Поэтому оно не может не тупить не в локалке. rdp гоняет контролы - то есть вся мишура экранная отрисовывается на клиенте (на сервере в случае vnc). Содержимое самих окон может передаваться как растр, тут не уверен. Но в целом это более "векторный" подход (образно говоря, как pdf: передаются шрифты, текст и его положение, рендерится на клиенте, изображение идет отдельно). Поэтому тут важнее насколько rdp клиент понимает про какие такие контролы ему талдычит сервер, откуда их брать, как отрисовывать и что именно с ними ему делать. Подозреваю, что тупой rpd клиент все сведет к передаче растра с сервера и будет не сильно лучше vnc.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	91. "Первый стабильный выпуск проекта Linux Remote Desktop"	–2 +/–
	Сообщение от test (??), 01-Янв-22, 08:06
	это шутка дня просто! покажите исходники хоть одной реализации RDP где это реализовано? все что я смотрел сам там обычно растр сжатый, как и во всех реализациях VNC где реализованы намного эффективнее алгоритмы.
	Ответить \| Правка \| Наверх \| Cообщить модератору