Доступен выпуск проекта Linux Remote Desktop 0.9, развивающего платформу для организации удалённой работы пользователей. Отмечается, что это первый стабильный выпуск проекта, готовый для формирования рабочих внедрений. Платформа позволяет настроить Linux-сервер для автоматизации удалённой работы сотрудников, дающий пользователям возможность по сети подключаться к виртуальному рабочему столу и запускать предоставленные администратором графические приложения. Доступ к рабочему столу возможен как при помощи любого RDP-клиента, так и из web-браузера. Реализация управляющего web-интерфейса написана на языке JavaScript и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56435
Почему во всех эти поделках всегда такая ощутимая задержка? Причём, даже не в одной локалочке, а на одном хосте. Я единственный, кто это наблюдает?
Меньше всего тормозит xpra и проброс хсервера. Более менее юзабелен vnc и spice.
Все остальное это страх и ужас.В линуксах сильно нехватает аналога нвидийного https://moonlight-stream.org/
Это пока единственный способ расшарить десктоп из офиса домой и из дома в офис который даёт на 95% локальный экспириенс для использования CAD софта.
Уху, правда текущий срез xpra сломан :( Но Antoine хорошо чинит, а я ему помогаю )))
И да, я для CAD-ов даже на планшете еще в 13м году пользовал Splashtop Enterprise. Солид и катьку крутил на ура!
Написано что есть moonlight-qt и в релизах есть AppImage для линукса, почему сказали что не хватает? Я ни разу не пользовался этой технологией, интересно узнать что это и зачем.
Потому что это клиенты
Клиент в линуксах отлично работает, но хост пиписитарный только от нвидии под виндой.
VNC — юзабелен. Да это шутка дня просто.
> Это пока единственный способ расшарить десктоп из офиса домой и из дома в офис который даёт на 95% локальный экспириенс для использования CAD софта.vnc придуман 150 лет назад.
А покажите реальный годный пример хорошего воплощения этого vnc в реальных боевых условиях? А то я за всю жизнь ни разу не видел такого. Или 8цветов палитра, или сиди смотри как перерисовывается слайдшоу и глюки. Работу в CAD я себе не представляю в таком виде. А если говорить ещё и о передаче звука, то он вообще, в принципе не пригоден.
да вот жеvncviewer 62.109.24.208
https://www.opennet.me/opennews/art.shtml?num=55401
С CAD-ом, похоже все зависит от самого CAD-приложения.Для виндовых ZWCAD, BricasCAD и AutoCAD, вне зависимости от клиента и протокола BricsCAD тормозит сильнее, чем AutoCAD. ZWCAD практически не имеет задержек по RDP, но не видит лицензию, по VNC иногда бывают лаги с выделением.
Под Linux нативные BricaCAD не хочет работать нормально ни через перенос вывода X-оы, ни через VNC, ни через Spice. Дикие задержки перерисовывания выделения. При этом на этих же хостах QCAD и LibreCAD таких тормозов не имеют.
nomachine же
И что с того? Нет привкуса смузи?
Есть sunshine
Поделитесь, пожалуйста, ссылкой. Без этого ничего подобноно найти не удаётся
Пожалуйста
https://github.com/loki-47-6F-64/sunshine
Поддерживаю.
Разворачивал сервера с разными реализациями и заметил что на лине потребление трафика больше 10мб на пользователя. Если сервер развернуть на ms, то при тех же условиях нагрузка на сеть меньше 1мб. Так и не понял с чем связано.
связано с тем что на rdp в линкусе всем плевать и делаю подделки на костылях?
С тем, что Windows изначально заточен на работу с графикой: приложение Win32 получает запрос от операционки на перерисовку кусочка своего окошка, а не всего целиком. Соответственно, «родной» RDP гоняет по сети только эти кусочки.А как сделали интеграцию rdp с X-server, не известно. Возможно, что все окно приложения на каждый чих гоняют.
VNC пытается это решать, если я правильно понимаю, сравнивая кадры экрана по квадратам и находя различия.
> приложение Win32 получает запрос от операционки на перерисовку кусочка своего окошка, а не всего целиком. Соответственно, «родной» RDP гоняет по сети только эти кусочки.Ах, как было бы прекрасно, еслиб это было правдой на 100%... Увы но нет, точнее - не всегда у него получается. Чтоб в этом убедится - поставьте на десктоп картинку поболее, зайдите туда по RDP и подвигайте любое окошко...
Это проблема *любого* удаленного графического терминала - как только попадается большой растр, он начинает нещадно тормозить. Собственно как я понимаю - есть три решения, все плохие:
1. Вообще не использовать растр - только вектор. Даже текстуры. Результат немного предсказуем, сами понимаете - тяжелое детство, квадратные игрушки... :) Промежуточный вариант - загрузить все необходимые текстуры до начала работы, что сами понимаете не совсем реально... :)
2. Обрабатывать всю графику на сервере, а на клиента - тупо гнать видеопоток. Даже для игр - плохо, рассинхронизация (лаг) между действиями юзера и их последствиями на экране - неизбежна. Ну и канал дико жрется.
3. 10GbE с его RDMA. Ключевое слово - RDMA. Еще никто не сделал, насколько я знаю и работать будет исключительно в локалке.
Я по долгу службы много имел дело с разными терминальными решениями и по запросу выправлял работу этих серверов у разных компаний от мала до велика. Я поголовно вижу проблему с пониманием этих технологий. В России еще и с русскоязычной документацией плохо, а читать по-английски умеют не все, поэтому появляются всякие домыслы, вроде ваших трёх пунктов.Во-первых, есть 2 задачи, которые решают терминальные сервера:
1. Доставка удаленного приложения до пользователя
2. Организация удалённого рабочего места для пользователя.
Эти задачи имеют разную природу. В первом случае системный администратор хочет унифицировать приложение и доставить его любому пользователю на любое устройство, даже то, которое аппаратно не поддерживает запуск бинарного файла (x86 на ARM самый частый вариант). Второе - это задача организации унифицированного рабочего места сотрудника с последующей подачей этого рабочего места на тонкий клиент, во внешний интернет на недоверенное устройство или вовсе на бездисковую станцию.Технически в основе сессионного терминальника лежит не столько графическое API, сколько специфически затюненный под эту задачу планировщик процессов ядра ОС. Если вы пользовались терминальными службами Windows и разрабатывали под них, вы знаете что у Windows несколько планировщиков процессов. Например, при установке служб RDS происходит смена планировщика на специфическую реализацию Fair Use относительно сессий. Задачу которую решает терминальный сервер - разделить ресурсы одного сервера одновременно нескольким пользовательским сессиям так, чтобы один пользователь не повесил весь сервер. Современная реализация этого планировщика (Windows 10+) сцеплена с другими драйверами позволяет делить iops-ы на на диске и сеть.
А что если мы хотим выдать одному пользователю больше ресурсов чем второму? На сессионном терминальнике - ничего. А если у нас сессия пользователя содержит тонну фоновых процессов, части из которых нужен свой планировщик для быстрой работы? А ничего!
Я приведу примеры:
- Никакой
продолжение 1:сессионный терминал не может работать с SQL-,fpfvb
- Никакие фоновый процессы не могут быть задержаны по диску в рамках той же сессии в которой выполняется основное приложение.Отсюда должно стать понятно, почему для современных удаленных рабочих столов применяется 2 планировщика.
Один который делит пользователей - инфраструктура фиртуализации
Второй который делит процессы.Вся современная задача по удаленному рабочему месту целиком перешла на инфраструктуру виртуализации.
Вот вам самый частый признак некомпетентного сотрудника:
Развернуть сервер терминалов в форме виртуальной машины, сделать его для пары приложений, дать полную сессию. А потом у них это всё тупить начинает.Если задача давать приложения - ставьте сессионный терминальник. Полные сессии - делайте виртуальные десктопы. Ресурсы +/- те же но вы избавлены от проблем с планировщиком процессов сессионного терминальника.
Далее подумайте, он кодирует видео на сессиях. Если у вас включен SMT - у вас будут лаги и задержки. Если у вас виртуальные рабочие столы, то их профили можно и нужно подтюнить под SMT для снижения задержки.
Продолжение 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, потому что только он умеет всё и сразу.
> Все эти векторные кодеки совершенно не актуальны в условиях композитных рабочих столов. Даже на WindowsЯ в курсе. В ТЕОРИИ - можно сделать рабочий стол на чистых WinForms или иксах, практически без использования растра... Но это - только в теории. На практике - это будет возврат во времена twm
> Отсюда ваш пункт 1 умер много лет назад не актуален и забудьте вообще.
Я в курсе - привел ради истории :)
Продолжение 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. Вы просто о них не знаете, потому что цена этих решений отобьёт у вас даже желание о них читать.
Вы правы только в том, что всё это работает только в рамках локальной сети, но для совсем удалёньщиков вы все равно обязаны поставить шлюз/балансировщик/прокси-сервер или чем вы там доставляете поток наружу...
Спасибо за подробную лекцию, но я знаю что такое RDMA, как оно работает и откуда оно родом. :)> Вы просто о них не знаете, потому что цена этих решений отобьёт у вас даже желание о них читать.
Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "CAD-решение на VDI, на блейдах разумеется, на не одну сотню рыл." По сравнению со стоимостью TeamCenter+NX - копейки :)
> Я всё это пишу к тому, что это всё уже существует. RDMA настраивается на сети.
Да-да, начиная с 10GbE - штатно.
> Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "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 именно на передаче буферов по терминальным соединениям не применимо даже в локальной сети. Только в рамках кластера виртуализации/терминалов. Не понятно только что там этот кластер тогда делает... зачем он сам себе свои приложения показывает... Ну на шлюзы свои во внешку разве что передаёт.
rdp и vnc протоколы разного уровня.vnc тупо гоняет экран (образно говоря, целиком растровое изображение). Поэтому оно не может не тупить не в локалке.
rdp гоняет контролы - то есть вся мишура экранная отрисовывается на клиенте (на сервере в случае vnc). Содержимое самих окон может передаваться как растр, тут не уверен. Но в целом это более "векторный" подход (образно говоря, как pdf: передаются шрифты, текст и его положение, рендерится на клиенте, изображение идет отдельно). Поэтому тут важнее насколько rdp клиент понимает про какие такие контролы ему талдычит сервер, откуда их брать, как отрисовывать и что именно с ними ему делать. Подозреваю, что тупой rpd клиент все сведет к передаче растра с сервера и будет не сильно лучше vnc.
это шутка дня просто! покажите исходники хоть одной реализации RDP где это реализовано?
все что я смотрел сам там обычно растр сжатый, как и во всех реализациях VNC где реализованы намного эффективнее алгоритмы.
Кто-то тестил сабж? Задержка есть? Пользоваться удобно? Так -то вещь удобная для своей цели
Из сабжа гонял xRDP. На разных машинах с разными DE результат разный.
С Mate - нормально, но не на офисном процессоре. С Fly нормально и на целероне работает.Но Fly еще найти надо, если не пользоваться Астрой.
В ряд ли в контейнере ситуация кардинально изменится.
Я раньше кучу всего перепробовал. И пришёл к выводу что на линуксе лучшую реализацию удалённого стола, сделала valve. Steam remote play, у меня работал с минимальной задержкой, при этом умеет в звук.Единственное, для корпоративных целей, это скорее геморрой, но в отличии от TeamViewer, меня ни разу не подводил, когда нужно было показывать тяжёлые проекты.
Погодите, а раньше что - так нельзя было? RDP, проброс иксовых сессий..? Не пользовался. но слышал.
докеры-шмокеры...
Когда пользователей больше одного - замучаешься настраивать, кому какие приложения можно запускать и какие ресурсы предоставить. Как я понял, штука из новости это всё автоматизирует и через web-морду позволяет всем управлять.
> Когда пользователей больше одного - замучаешься настраиватьВот и выросло поколение…
Раньше это называлось LTE.
Т.е. стартовал gdm на машине, монтировал по nfs файловую систему сервера, и запускал Х11 сервер у себя на клиенте. Проги работали на сервере с Х11 клиентом.
https://ru.wikipedia.org/wiki/LTSP
они переименовались?
помню LTSM есть какой то на github
Раньше было сложно сейчас все просто с новым смузидистрибутивчиком.
раньше ещё в школе русский язык учили
а ты прагилифал ?
Зачем что-то делать просто если можно сделать сложно?
Ну вот.
-
RDP неплох, но, сколько ни пробовал, всё равно по Интернету заметно тормозит - во всяком случае, в Linux (к Windows подключаться не пытался). Проброс X по ssh - вообще за гранью. Пока что лучшее, что довелось испытать - X2Go, через него более-менее комфортно работать.
Попробуйте NoMachine. Если не коммерческое использование то вполне прилично работает, а x2go кстати использует старый протокол NX от NoMachine
Более того, NX - единственный позволяет подключаться к уже запущенным Х-сессиям ЕМНИП.
> Более того, NX - единственный позволяет подключаться к уже запущенным Х-сессиям ЕМНИП.xrdp может:
```xrdp.inifork=false
```
все что завязано на freerdp это обычный сжатый растр. намного хуже чем норм zrle от vnc.
А что там с передачей русских текстов через буфер обмена VNC?Таки исправили? И как это применить к тому же TigerVNC к примеру?
таки исправил кто и где? как это применить к тигервнс обратитесь к тупым разрабам тигервнс же
в стандарте RFB есть copypaste проблема клиент серверной реализации ваша проблема а не наша!
Дистр для браузера ещё не создали? А дистр для прослушивания музыки или просмотра фотографий? А может дистр для калькулятора уже существует? 🤔😆
🖕
>Дистр для браузераChrome OS
> первый стабильный
> 0.9почему бы просто не использовать версию 1.0 и всем бы стало понятно?
Авторы как бы намекают на уровень стабильности.
В SemVer не значит "чем больше цифра, тем стабильнее". Удивлен твоему количеству плюсов.
Ты слишком хорошего мнения о местной публике.
Удивлён твоему удивлению!Там не "больше цифра", там первый *не ноль*.
для лл:> Реализация управляющего web-интерфейса написана на языке JavaScript
> Проектом предлагается готовый docker-контейнер
> RDP
"ssh -X" намного лучше всяких захватов экрана целиком.
Не по глобальной сети
ага, только в миллиард раз медленнее даже по локалке
Как-то требовалось контролировать работу IPTV на узле провайдера, имитируя абонента ШПД. Клиент был в виде виртуальной машины в ЦОД провайдера. Единственный нормально рабочий вариант, который устроил - NoMachine. Адаптация под полосу пропускания работает на 5, комфортно смотреть видео с удалённого сайта как с фиксированного, так и с мобильного доступа, одинакого, что на десктоп, что на Android телефоне/планшете. Бесплатно только однопользовательский клиент/сервер. В Enterprise версии уже многопользовательский доступ есть. А VNC/SPICE/RDP в данном кейсе - слайдшоу.
Теперь понятно откуда у таких "прывайдеров" затыки в трансляциях!
Я уж думал никто и не впомнит про NoMachine, работает то он классно и на венде можно поставить и на хоум версию и на лине тоже работает очень прилично, вполне можно смотреть видео, неговоря уже про шустый отзыв, единственный минус - лицензия, которая только для дома, а если брать под бизнес, то цены очень близко к teamviewer подбираются
и почему rdp?
чем это лучше остальных vnc/etc ПО?
если не рассматривать через призму сотен виндоклиентов rdp на винде
если ты не знаешь, чем rdp лучше vnc, тебе стоит подучить матчасть
>работа без использования VPN.Разумный админ корпоративной ИТ-инфраструктуры этого не допустит.
На рабочем месте не нужен браузер с интернетом?
И от чего тогда спасает подключение клиента по vpn?
У тебя юзер играет в русскую рулетку, но пусть наденет респиратор и поставит прививку.
Прививку не "ставят", а делают.Ставят клизму и капельницу.
Таки да, в 90% интернет на _рабочем_ месте не нужен. А если и невозможно в оставщихся 10% случаев без него обойтись - ИБ всё равно заставят гонять траф через корпоративный Firewall с политиками безопасности, потоковым антивирусом и прочими энтерпрайсными плюшками. Иначе первый же "шифровальщик" поставит всю контору раком...
Ды конечно. Пользуюсь этим XRDP - у него соединение падает постоянно, особенно при какой движухе на экране.
> 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=nonebitmap_cache=true
bitmap_compression=true
bulk_compression=true# И самая гланая вишенка на тортик:
max_bpp=16
==============
А когда оно научится переключать раскладки в форме авторизации, позвольте спросить?
> А когда оно научится переключать раскладки в форме авторизации, позвольте спросить?Понятия не имею.
Такие вопросы думаю уместны здесь: https://github.com/neutrinolabs/xrdp/issues
А как на счет звука почему никто не говорит, есть стабильная двухстороняя трансляция или ее нет ?
может зависеть от наличия\отсутствия драйверов, их качества, а также поддержки 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
И интерфейс под мобильные пальцетыковые экраны.
Горите в аду.
А теперь https://thinstation.org/ нельзя использовать?
Как то пришлось NoMachine ползоваться. Вот это качество! Совершенно гладкая передача экрана была.А вот у них и терминальный сервер есть:
https://www.nomachine.com/ru/terminal-server
> Как то пришлось NoMachineИ чем x2go хуже?
NoMachine - жмет поток аппаратно с h.264 потому и скорость и качество, a x2go юзает то самый модефицированный NX протокол, который разработали в NoMachine
> NoMachine - жмет поток аппаратно с h.264 потому и скорость и качество,
> a x2go юзает то самый модефицированный NX протокол, который разработали в
> NoMachineт.е. умеет жать там, где есть аппаратная поддержка сжатия? Тысячи вебкамер их клиенты?
> т.е. умеет жать там, где есть аппаратная поддержка сжатия?Я не пойму, это риторический вопрос или вы и правда не знаете, что большинство компьютеров уже имееют на борту h.264 (даже недо-видео карты в составе ЦПУ на интелах имеют QuickSync начиная с 4-го поколения кажется)
> Тысячи вебкамер их клиенты?
Гхм... А что уже есть вебкамеры с полнозначным desktop environment, чтоб там можно было мышкой пошевелить что нибудь???
> правда не знаете, что большинство компьютеров уже имееют на борту h.264чем это вам поможет?! с чего вы решили что от терм сервера на клиент идет 264?
> чем это вам поможет?!Скорость друг, скорость ! И качество
> с чего вы решили что от терм сервера на клиент идет 264?
те там на каждого клиента постоянно HD видео кодирует? на терминальном сервере работать может человек 20-30 в вашем варианте вообще программы работают?
для одного рабочего места нормально!
> те там на каждого клиента постоянно HD видео кодирует?Не на клиенте, а на сервере
> на терминальном сервере работать может человек 20-30 в вашем варианте вообще программы работают?
Работают программы, нормально. Если б вы сталкивались с blueiris, то обнаружили бы, что можно и больше чем 30
> Я не пойму, это риторический вопрос или вы и правда не знаете,
> что большинство компьютеров уже имееют на борту h.264 (даже недо-видео карты
> в составе ЦПУ на интелах имеют QuickSync начиная с 4-го поколения
> кажется)Лично у меня кодирование h.264 идет со скоростью 4-6 кадров секунду. Комп не из большинства, очевидно.
> Гхм... А что уже есть вебкамеры с полнозначным desktop environment, чтоб там
> можно было мышкой пошевелить что нибудь???Зато вот они умеют один поток кодировать в реальном времени и порой даже в h.265 (HEVC)
Эээ, не скажу, не пользовался. Возможно тоже хорошее
> Эээ, не скажу, не пользовался. Возможно тоже хорошеевыше по треду хвалили, и в в принципе оно в локалке смоотрится так же.. в глобалке впрочем не пробовал.
Пихать в один! TCP поток видео, звук и данные от принтера например это очень медленно.
Чего ваш RDP и делает с успехом. При печати весь графоний встаёт колом!
Не очень понятно, зачем весь десктоп тянуть, если работаем мы с приложениями, а не на десктоп пялимся.
Я уже лет пятнадцать именно так из-дома, если нужно, программирую -- в одном терминале ssh -Y, в котором slickedit, в другом (третьем и более, если нужно) остальное, рабочая почта, например. Чувствую себя, как будто прямо на фабрике работаю.С другой стороны, x-сессия в сети 10 Мбит/с тоже нормально работает. Разумеется, если все свистоперделки бессмысленные, вплоть до визуализации перемещения содержимого окна, отключить нахрен.
Поставил этот Linux Remote Desktop
каждая новая сессия = новый предустановленный докер образ + приложения подключенные через веб интерфейсустановка простейшая,
из плюсов - работает шустро, базовые вещи есть
из минусов - хромиум не заводится по неизвестным причинам, каждый раз слетают настройки до базовых из предустановленного докер-образа(локаль например, настройки в прокинутых приложениях)
вроде прикольно, но пока что подходит только для класса информатики, для работы пока не допилено
