Удалённый рабочий стол с двумя мониторами

RDP точно так может.

А сервер для линукса у него есть? С клавиатурой у него всё нормально? У меня были проблемы с tigerVNC с двуязычием, потом появилась опция RawKeyboard и рассосалось. Также надо, чтобы на сервер отправлялись всякие сочетания типа Alt-Tab. Rdp это умеет?

Вспомнил, что уже перебирал этот вариант с rdp, и скорее всего что-то работало не так, как надо. Пока что запустил два tigervnc, как-то так:

tigervncserver -geometry 800x600 :0 -RawKeyboard=1  &
disown
tigervncserver -geometry 800x600 :1 -RawKeyboard=1  &
disown

Соответственно, далее на клиенте запускаю wsl2, в нём ssh к линукс-машине с пробросом портов 5900 и 5901 и два vncviewer запускаю с localhost:5900 и localhost:5901 . 5 минут полёт нормальный, буфер обмена получился общий, один vncviewer сделал полноэкранном на одном мониторе, alt-tab отправляется на сервер как надо, раскладка переключается, хотя на каждом клиенте отдельно (возможно, с этим будут неприятности). Конечно, окна с одного монитора на другой перекинуть нельзя, но это лучше, чем ничего. Просто вспомнил, что потратил немало времени на это, а времени жаль.

Ubuntu 22, сервер 1.12.0, клиент под виндой - 1.15.0

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

Я что-то не могу нагуглить krdp для винды. Я пробовал через wsl2 запускать разные графические приложения для линукса, они почти работают, но качество, так скажем, прихрамывает, пока рано сказать, что я мог работать. Т.е. можно попробовать запустить krdp под wsl, но я бы оценил вероятность успеха как невысокую, а вроде пока и так жить можно. До этого несколько месяцев сидел с одним экраном - теперь шаг вперёд. Так что спасибо, может быть в следующий раз.

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

mstsc сто лет как есть

С ним были проблемы, см. список требований. Не помню, какие именно. Но я от этого варианта отказался. На 7-й минуте ракета захромала. А именно, запустил браузер на одном экране, а он запустился на другом, на котором не надо. Как я это исправил?

• браузер Mozilla вообще не запустился, что-то там с шиной сообщений, требует какой-то авторизации, послан
• Яндекс-браузер любит сидеть и шпионить, когда его даже закрыли. Т.е., если он один раз запустился не на том экране, закрывать и открывать его бесполезно. И может быть, гад, сам стартует при запуске системы. Поэтому killall yandex_browser и потом из командной строки на нужном экране пишем yandex-browser (sic).

есть еще rx eterosoft, loudplay но оно за деньги

Если rdp не подходит, то только за деньги можно что-то более-менее вменяемое получить.

Что именно в tigervnc у тебя не работает? У меня в скрипте можно выбрать любую конфигурацию

if [ "x$MONITOR" = "xAll" ]
then
	VNC_ARG="$VNC_ARG -FullScreenMode=All"
elif [ "$MONITOR" -eq "1" ]
then
	VNC_ARG="$VNC_ARG -FullScreenMode=Selected -FullScreenSelectedMonitors=1"
elif [ "$MONITOR" -eq "2" ]
then	
	VNC_ARG="$VNC_ARG -FullScreenMode=Selected -FullScreenSelectedMonitors=2"
else	
	VNC_ARG="$VNC_ARG -FullScreenMode=Current"
fi

vncviewer $VNC_ARG Shared $SERVER

Правда linux<->linux

Работает всё, но полноэкранность работает не так, как надо. Один монитор чёрный, на другом - только фон рабочего стола.

вы там все много букав написали, я признаться — все это словоблудие в «GPL и пермиссивное ПО» до конца ниасилил.

но вот что я понимаю по этому вопросу:

• ЯОС как модульная оперативная среда A2/Active Oberon заместо операционной среды-программы-движка ядра Си с модулями-драйверами и комодулями init 1 и шеллом и метадрайверами

• допустим, мы делаем литературно-грамотный Оберон, возможно даже – Активный Оберон, возможно даже кириллический сиречь ЯОС.

• любая операционка – лишь приставка для запускалки нужных программ. что это за программы ?

любой юникс интереснее приставки-венды от патентованных вендоров фсея венды – конструктивно, по построению. ибо это есть движок системы с init 0 -> init 1 и далее модулей системы сиречь драйверов и далее демонов и шелла и юзерлэнда, сиречь ld.so file.elf libc.so

• что меняет в этой ситуации модульно-компонентный Активный Оберон сиречь A2 пассивный оберон сиречь BBCP Component Pascal сиречь кириллический А2 сиречь ЯОС?

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

на второй взгляд – метасистема. не просто техническая система систем богу данных а метациклическая коэволюция бутстрап-систем – богу метаданных

обратимся же в поисках сиих к искусству программирования: Art Of CP, Tex: The Program -- and The Book : weave.web, tangle.web, tex.web и потомки его.

Дональд Кнут (конечно, крут) – написал книгу по алгоритмам, в искусстве программирования оных. на этом он не успокоился: создал метасистемы:

• TeX для техне документирования

• WEB литературно-грамотный для метапрограммирования.

в поддержку продукта «TAOCP» получилась метатехнология WEB и weave/tangle технология грамотно-литературного человеко-сценарного метапрограммирования:

** коэволюция бутстрап систем и метасистемный переход — от книги-артефакта «компутерной тупографии» в ея алгоритмы сначала на алголе SAIL, затем на метапаскале псевдокода Pascal-H – затем в метадистрибутивы TeX-движка по типу: e-TeX, PDFlatex, XeLaTeX, LuaTeX.

коэволюция идет во все стороны: например, псевдокод изначальный был на метапаскале Pascal-H, который бутстрапно самораскрутился в weave/tangle императивного тех-движка даже с метадистрибутивами типа уникодного, PDF-TrueType-embedded-fonts и скриптового недо_паскаля_ LuaTeX.

предположим, в альтернативной вселенной – у нас есть gcc 16 и метадистрибутивы лавки модульных метаязыков: ga68 алгола 68, модулы-2 gm2, ады GNAT (.. и оберонов и активных метаоберонов и зоннонов).

допустим, алгол 68 ga68 все еще достаточно хорош для tex-а, словно algol-68Genine интерпретаторо-недокомпилятор для какой-то бутстрап системы словно BBCP или A2/ЯОС в новой версии.

что же может дать всем нам литературное метапрограммирование и эволюция в эту сторону?

• во-первых, обезглюченность.

• во-вторых, доработку по требованиям.

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

• в-четвертых, метасреду типа A2/ЯОС для реализации «литературно-грамотной TeX-среды на базе WEB и weave/tangle изначального», канонiческого да с – доработками.

что же это за доработки?

положим, что же даёт нам по сути – _литературное метапрограммирование _ ? какую новую степень свободы?

• во-первых, и главных – это языконезависимость

для «алгоритмов контуперной тупографии» – по сути не так уж важно на каком ЯП вообще реализованы все эти _(мета)_алгоритмы.

TeX изначальный, канонiческий Дональда Эрвина Кнута чисто исторически – был реализован в 1976-1982 сначала на алголе SAIL, затем переписан на паскакале Pascal-H псевдокодовом

положим, в альтернативной вселенной – мы на этом бы да не успокоились, и дабы не упокоиться навеки – еще несколько раз переписали:

• на алгол-68, ga68 в gcc16 и на Algol-68-Genie. в духе интерпретатора, конпелятора, монитора как в PL/I и модульно-компонентного запускатора.

• на модула-2, ада, FPC, …

• на обероне пассивном из BBCP и документ-ориентированном литературно-грамотном интерфейсе с коммандерами-запускаторами weave/tangle и «вюьшками,контролами,персистентыми объектами» в литературно-грамотном гипертексте *.odc объектов-компонетов в BCF framework

• и на обероне активном, акторном из A2 или ЯОС.

Reason? Profit! мини-дистрибутив TeX изначального как не паскалепрограмма, а активно-оберонисто-акторная литературно-грамотная метасреда : модульная компонентная среда литературного метапрограммирования

что такое эта хвалёная языконезависимость ?

TeX изначальный был реализован на псевдокоде метапаскаля Pascal-H и развитии движка его сначала в уникодовость и «PDF из коробки с embedded True Type фонтами», затем в LuaTeX для метавычислений на луа-калькуляторе.

но вот рассмотрим подробнее tex.web и например, Tex-FPC/ TeX-GPC как метадистрибутивы ево как набор патчей, патчсет change-файлов.

здесь мы видим оригинал и перевод, и подстрочник.

например: *.ch патчсет TeX-FPC погружает метаперевод в другую среду, другой язык, ЯП и его среду – из TeX Pascal-H => в TeX-FPC.

допустим, мы бы накалякали не просто TeX-ga68 а например и на модуле и на аде и даже – на активном обероне, или ЯОС.

акторный литературно-грамотный векторный гипертекстовый метапрог

эта хвалёная языконезависимость по сути означает – память переводов

из псевдокода _мета_паскаля изначального Pascal-H – в среду модулы, ады, оберона пассивного… или акторного да активного.

то есть, diff в виде *.ch change файлов – это перевод с паскакаля Pascal-H ISO Pascal в новую среду, с новыми реалиями.

допустим, мы эту среду литературно-грамотно далее расширяем, осуществляя метасистемный переход:

• расширяем язык документирования .tex -> в .asciidoc подобное маркдаунное нечто

• расширяем язык метапрограммирования .web -> в полноценное управление конфигурацией, управление требованиями (в лисп-подобный SCRIBE-подобный .skribillo-на-гуйле AST reader/writer метязык лисповой макросни)

• расширяем язык кодирования Pascal-H –> в некий неведомый доселе псевдокод метапаскаля и потомков ево: algol-68, modula-2, Oberon-2 BBCP обероны пассивные, A2/ЯОС акторныя обероны активные

==> получаем среду или даже метасреду для разработки литературно-грамотных документов-компонентов – типа *.odc с +-«вьюшками и контролами на персистентных хранимых объектах оберона-2, метаоберона, оберона акторного да активного»

как же могла бы выглядеть такая метасреда, метасистема ???

• во-первых, языконезависимость через управление требованиями через управление конфигурацией :

аналогично doorstop на пистоне на *.yaml файлах – хранить требования в .asciidoc подобном с гиперссылками и матрицей трассировки автогенерируемой

• во-вторых, какой-то фреймворк для управления метаконфигурацией

и

• в-третьих, для ея – суперкомпиляции

то есть: есть код и есть метакод.

код – это реализация требований на каком-то произвольном ЯП.

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

то есть: первое что нужно сделать в литературно-грамотном дистрибутиве тех-как-метапроцессора – это

– управление конфигурациями

второе – управление требованиями.

далее, есть кот. на каком-то ЯП.

и есть перевод. этого кота на другой ЯП.

например: патчсет *.ch - change-файлов с tex.web Pascal-H => алгол-68, модула-2, ада.

.. или, оберон-реализацию.

как продукт первичный: получаем мини дистрибутив теха на обероне – активном или пассивном.

как продукт вторичный – макропроцессор над *.web файлами и патчсетом *.ch change-файлов для управления требованиями над всем этим.

например, собрать какой-то конпедимум для тестов с альтернативными реализациями: TeX-Pascal-H(LuaTex,ConTeX, Latex, XeLaTeX) , TeX-FPC, TeX-Ada, TeX-A68, TeX-O2, TeX-AO2, TeX-ЯОС

c табличкою типа размеров бинарника, user time, systime, ldd со всеми зависимостями.

например, сделать в первом приближении A2/Active Oberon модульную и зело компонентную реализацию TeX: the program and the book – уже достойная награда – в сторону развития minimal self-sufficient TeX (meta)distributive

далее следует развивать литературно-грамотное IDE

и погружать его через управление требованиями, управление конфигурацией в полноценное IDE.

языково-нейтральное и потенциально обезглюченное аки TeX ибо литпрог как память переводов на другой ЯП

в общем, вопрос: Денис, что ты думаешь о подобной **(мета)**системе?

… и ее – метасистемном переходе, ога

вы там все много букав написали

Вы тоже немало. Я сейчас вообще программированием занимаюсь только на работе. Ничего не думаю. Литературное программирование сегодня - это ChatGPT. Да, он далёк от совершенства, но диалог с высокоумной системой в форме чата - это наше будущее. Началось оно уже давно, когда появился SQL, сейчас сделан следующий шаг. Можно было бы завести отдельную тему под это, но я не особо заинтересован обсуждать.

krdp для винды

Там из коробки родной клиент, протокол-то виндовый.

Там из коробки родной клиент, протокол-то виндовый.

Кстати, интересный момент. Я когда ещё работал с виндовыми компами на работе и нужна была удалёнка, нам дали RDP через корпоративный VPN. И в виндовом родном клиента оно дичайше тупило. А вот в линуксовой Remmina летало как самолет.

Т.е. я тупанул и имелось в виду, что я использую xrdp на стороне линуксового сервера, а обычный mstsc или как его там на стороне виндового клиента?

Ну… да. В винде есть и клиент и сервер. Дальше ты либо коннектишься к винде через линуксовый клиент, либо коннектишься виндой к линксовому серверу.

Я слегка выпал из этой темы и комп тот сейчас в ремонте. Чел вообще офтопик написал, видимо, куда-то нет доступа анонимусам. Но вроде тут выше по теме я писал, что пробовал какой-то вариант с rdp и остался недоволен. Был ли это именно xrdp - я не знаю, но я точно должен был попробовать на клиентской стороне mstsc - я про него знаю уже много лет как. Ладно, можно ещё раз попробовать при случае.