Если скорость копирования с фотоаппарата на комп действительно не так уж важна, то незачем даже вынимать карточку, большинство фотоаппаратов можно подключить к компу по USB и копировать файлы напрямую.
в андроиде есть графика, андроид открыт, почему не использовать их решение для графики, зачем wayland?
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Вот не надо пытаться "поддерживать темы и стилизацию конкретного DE". <...> Ну а общий стиль декораций - это именно атавизм <...> одинаковые они не потому, что кто-то так захотел, а потому что декоратору проще рисовать всегда одинаково
Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился?
Что за чушь Вы несете?
декорации окна под голым вейландом делаются примерно настолько же просто как и обычная кнопка <...> проблем у бестулкитных программ в мире CSD вообще нет
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я даже не знаю насколько пофиг должно быть на всех и вся, чтобы считать что это допустимый вариант.
И SSD эту проблему не решает вообще никак, даже частично.
SSD решает эту проблему целиком и полностью. Просто по построению.
если разработчик "ожидает по умолчанию" - это проблема разработчика, он, видимо, не до конца понимает, под какую среду он пишет
Да прекрасно все мы понимаем, под Gnome. Ни в каком другом случае этот вопрос даже не поднимался бы. Только в Gnome ожидания пользователя (в данном случае пользователя API) это проблемы пользователя, и вообще это вам не надо, а надо сплясать вприсядку и подставить костылей чтобы в итоге все равно получить точно то же самое, потому что иначе никак.
Это если в обязательном порядке есть тулкит, в котором есть поддержка тем и нюансов стилизации конкретного DE.
Во-первых, приложению может быть и не нужен тулкит, если у него нет обычного UI. Когда началась эта катавасия с CSD в Gnome, отвалилось оформление целой кучи разных приложений: игры, плееры, терминалы. Часть потом полечили поддержкой libdecor в SDL, но это не исправляет суть проблемы. Зачем приложению тажеленная зависимость от тулкита, если оно им не собирается пользоваться?
Во-вторых, мир опять-таки не ограничивается GTK и Qt. Формально, в Linux может быть неограниченное количество самых разных тулкитов для самых разных целей, и все они должны поддерживать возможные закидоны всех мыслимых DE?
Общие декорации это не атавизм, а то, что ожидает разработчик приложения по умолчанию. В подавляющем большинстве случаев они предоставляются тулкитом, но вариант создания окна напрямую через X или Wayland ничем по смыслу не отличается от создания окна напрямую через WinAPI или Cocoa. Если бы у Linux был бы один официальный и всегда без вариантов доступный тулкит для UI, задачу декораций можно было бы переложить на него, как в случае с Windows или macOS. Но в Linux в качестве такого "тулкита" выступают X и Wayland.
Нормальные же люди будут юзать экраны с нормальным DPI
Я купил 4K монитор только потому, что устал смотреть на пикселявый текст. Поставил на 4K масштаб 200%, все по размерам осталось как и было, только текст теперь нормальный.
Да, на моменте с CSD я тоже понял что добром это не кончится.
Wayland не требует от композитора поддержки SSD, клиент все равно обязан быть готовым предоставить CSD, а еще нам лень, так что давайте все реализуйте CSD.
И ведь главное находятся защищающие эту позицию. Мол раз Wayland не требует, значит можно, нет, даже не так, это правильно не поддерживать SSD. То, что причина опциональности SSD (наличие сценариев, когда SSD не имеет смысла, например телефон или киоск) не имеет никакого отношения к десктопам, никого не интересует.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует. Используй GTK, что ты как маленький.
По какой-то непонятной причине мир GTK не ограничивается. Но поскольку предоставлять декорации по запросу клиента мы не хотим, сделаем специальную библиотеку libdecor, которая по запросу клиента предоставит декорации. Теперь любое приложение, которое не использует популярный UI-фреймворк, должно таскать с собой этот костыль для Gnome.
Для smart ptr нужны деструкторы. Их нет в стандарте
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
Для option/either/maybe нужны дженерики. Си может предложить только макросы
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.
Мир Линукс не в какой-то волшебной стране бесконечных ресурсов расположен. На что хватит сил из того, что наиболее востребовано -- то и будет поддерживаться. Остальное останется существовать в том виде, в каком есть, пока не устареет.
Грубо говоря дропнут поддержку X в очередном мажорном релизе фреймворка потому что тесты падают, а разбираться и фиксить их некому -- и все. Либо сам пили как хочешь, либо спонсируй, либо просто возьми уже свежую версию и не занимайся ерундой, вот и весь выбор.
Приложения перестанут его поддерживать целенаправленно. При использовании "чистых" Qt, GTK и т. п. все равно что за протокол используется, но полным-полно софта, которому надо или чуть больше, или что-то специфичное, или что-то, что в Wayland пока не реализовано, или просто X дёргает потому что ну он же у всех есть.
Так как Wayland стали ставить и включать по умолчанию, с этим софтом начнутся проблемы. Это криво, то не так -- эти проблемы будут исправляться с обеих сторон, что-то в приложениях, что-то в Wayland. В определенный момент окажется, что из всего дистрибутива XWayland не использует никто и его просто выключат. И вот тут можно будет сказать, что X кончился.
Ключевой момент текущих событий в том, что ещё недавно Wayland был сугубо экспериментальной штукой, которую надо было включать целенаправленно и обычно осознанно. Теперь наоборот это вариант по умолчанию. Если пользователь поставил свежую версию ОС и софт, а он глючит или не работает -- придется править. Чем больше будет исправлено и адаптировано, тем большей дичью будут казаться оставшиеся косяки.
X перестанут использовать осознанно, но его поддержка конечно останется ещё надолго. Только никому уже не будет до этого никакого дела.
Вообще я имел в виду прям вообще весь интерфейс. Не просто изображение какого-нибудь приложения, а прямо всё нутро UI, как это пытается делать X. Это сложно, это не всегда возможно и самое главное это никому уже толком не нужно -- любой клиент уже достаточно производителен, чтобы удаленный вызов самых различных функций по работе с условной кнопкой вместо передачи ее изображения был неэффективным и ненадежным кромчиловом.
Ваш сценарий работы довольно специфичен, но даже в нем X на самом деле не нужен. Ну, в смысле можно было бы сделать все то же самое и без X. Просто так вышло, что для X в силу исторических причин уже все есть, а для Wayland никто и не подумал делать.
Если будет спрос на чрезвычайно оптимизированный вариант проброса GUI окна или его части -- сделают и для Wayland. Но пока ситуация такова, что чаще всё-таки нужно пробросить рабочий стол или окно ровно как оно есть, со всеми особенностями и нюансами, один в один, и не морочить голову. Ваш сценарий работы может быть очень даже обоснован, но объективно ради небольшого количества человек никто не будет городить всю эту бесполезную канитель с выполнением GUI как будто это web-сервис какой-то на удаленной машине.
Ну и по конкретному сценарию работы. Вы же на локальной машине или хотя бы в локальной сети все крутите если я правильно понял. Зачем тут вообще проброс GUI? Локально есть просто монитор виртуальной машины, в локальной сети любой способ доступа к удалённому столу будет работать прекрасно. Более того, если окно виртуальной машины чем-то не нравится (я просто делаю его нужного размера и разворачиваю внутри окно нужного мне приложения в полный экран), то у VirtualBox и VMware есть seamless mode, который позволяет вытащить окно гостя на рабочий стол хоста.
Ну то есть это реально выглядит как решение проблемы, которой по сути и нет, а X это такой костыль, который чисто случайно подошёл.
Да, уровень поддержки X и Wayland сильно отличается. В одном будут править баги и добавлять современную функциональность, а во втором -- нет.
Приложения, которые не будут поддерживать Wayland, относительно скоро потеряют пользовательскую базу. Да, Wayland далеко не идеал, но X все. Можно сколько угодно сетовать, что в Windows 11 все плохо, телеметрия, кривое поделие с сомнительными решениями, и пытаться сидеть на вылизанной и стабильной XP -- но все, поезд ушел. Сидите сколько хотите, весь остальной мир будет жрать совсем другой кактус.
Qt, GTK и прочие фреймворки абстрагируют работу с элементами UI. Они предоставляют свой собственный API, а уж с использованием чего он реализован -- приложение, в идеале, знать не должно. В Linux они реализованы поверх X11 и, теперь, ещё и Wayland, в Windows -- поверх WinAPI, в macOS -- поверх Cocoa и т. д.
Qt это вообще один из наиболее популярных кроссплатформенных фреймворков для GUI, он в принципе не может работать только через X11.
Проблема комментариев, которые легко писать и поддерживать, в том, что они описывают что происходит, а не почему и зачем.
Что код/функция/модуль делает можно худо-бедно понять по самому коду. Куда важнее информация зачем вообще этот код нужен, почему код делает именно так, а не очевидно более простым образом и в каком направлении его можно менять, а в каком лучше не стоит -- пробовали, не получилось.
Но такие комментарии парой строк перед функцией уже не напишешь и такую информацию очень сложно поддерживать в процессе более-менее активной разработки.
Вот и получается, что описаний функций с аргументами полно, а логику и практики применения можно найти только в статье или вообще монографии опытного пользователя.
Соглашусь, утверждение было сформулировано слишком категорично.
Однако я имел в виду обычные, популярные протоколы доступа к удалённому рабочему столу, где не предполагается много видео. В таком случае старый добрый подход с как бы, типа, если один глаз закрыть, lossless передачей пожатых прямоугольников с изменившимися пикселями работает на удивление хорошо.
Хотя с современными кодеками, которые сами могут разбить кадр на произвольные области с индивидуальными параметрами сжатия, граница становится довольно размытой. Не удивлюсь, если к AV2 или H.266 проще и эффективнее будет тупо кодеком весь экран пожать с указанным битрейтом и не париться.
Вы вероятно плохо представляете, как сложен современный UI. Те "свистелки и переделки", которые навертели поверх того самого старого доброго X -- это уже неотъемлемая часть работы большинства приложений, от общей композиции рабочего стола до нормальных шрифтов и аппаратного ускорения.
Добрая часть UI уже давно не будет работать по сети в том виде, в котором это задумывалось в X изначально, часть вещей в принципе не может работать по сети и явно или косвенно опирается на предположение, что все локально. А худо-бедно прокидывается оно потому, что вместо высокоуровневых примитивов там передаются целые области изображения -- как в VNC (а не VPN, надеюсь вы просто опечатались), только криво.
В итоге "как задумано" оно работает только в примитивных сценариях, которые нельзя назвать общим решением. Либо оно работает так же, как и остальные протоколы, только ещё и X там ни к селу, ни к городу.
Во-первых, видео а-ля стриминг игр нигде и не перекачивается, ни в плохом качестве, ни в каком.
Во-вторых, если ни один из этих протоколов не работает если связь меньше мегабита, ну значит для этой задачи объективно надо мегабит.
X просто не подходит, даже если он по тоненькому каналу может работать. Если "не передавать контент вне оконных примитивов", ограничившись только чистым X, то это будет работать только с X, то есть в довольно ограниченном виде. Если вам хватает простецких окон терминала и блокнота с древними шрифтами -- прекрасно, остальному миру не хватило. Если же прокинуть через X десктоп с композицией, а в нем ещё и современный браузер, то там уже по сути VNC начинает ходить, то есть все те же копии картинок.
Если скорость копирования с фотоаппарата на комп действительно не так уж важна, то незачем даже вынимать карточку, большинство фотоаппаратов можно подключить к компу по USB и копировать файлы напрямую.
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Учитывая что почти все сейчас рисуется GPU, проброс X в общем виде деградирует до RDP/VNC.
Я вообще не понимаю о чем Вы.
Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился?
Что за чушь Вы несете?
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я даже не знаю насколько пофиг должно быть на всех и вся, чтобы считать что это допустимый вариант.
SSD решает эту проблему целиком и полностью. Просто по построению.
Да прекрасно все мы понимаем, под Gnome. Ни в каком другом случае этот вопрос даже не поднимался бы. Только в Gnome ожидания пользователя (в данном случае пользователя API) это проблемы пользователя, и вообще это вам не надо, а надо сплясать вприсядку и подставить костылей чтобы в итоге все равно получить точно то же самое, потому что иначе никак.
Это если в обязательном порядке есть тулкит, в котором есть поддержка тем и нюансов стилизации конкретного DE.
Во-первых, приложению может быть и не нужен тулкит, если у него нет обычного UI. Когда началась эта катавасия с CSD в Gnome, отвалилось оформление целой кучи разных приложений: игры, плееры, терминалы. Часть потом полечили поддержкой libdecor в SDL, но это не исправляет суть проблемы. Зачем приложению тажеленная зависимость от тулкита, если оно им не собирается пользоваться?
Во-вторых, мир опять-таки не ограничивается GTK и Qt. Формально, в Linux может быть неограниченное количество самых разных тулкитов для самых разных целей, и все они должны поддерживать возможные закидоны всех мыслимых DE?
Общие декорации это не атавизм, а то, что ожидает разработчик приложения по умолчанию. В подавляющем большинстве случаев они предоставляются тулкитом, но вариант создания окна напрямую через X или Wayland ничем по смыслу не отличается от создания окна напрямую через WinAPI или Cocoa. Если бы у Linux был бы один официальный и всегда без вариантов доступный тулкит для UI, задачу декораций можно было бы переложить на него, как в случае с Windows или macOS. Но в Linux в качестве такого "тулкита" выступают X и Wayland.
Я купил 4K монитор только потому, что устал смотреть на пикселявый текст. Поставил на 4K масштаб 200%, все по размерам осталось как и было, только текст теперь нормальный.
4k в 90 DPI это 3840 / 90 = 42.7 дюйма или 107 см по ширине. Либо у вас монитор с диагональю 48", либо все-таки масштаб 200% =).
Да, на моменте с CSD я тоже понял что добром это не кончится.
Wayland не требует от композитора поддержки SSD, клиент все равно обязан быть готовым предоставить CSD, а еще нам лень, так что давайте все реализуйте CSD.
И ведь главное находятся защищающие эту позицию. Мол раз Wayland не требует, значит можно, нет, даже не так, это правильно не поддерживать SSD. То, что причина опциональности SSD (наличие сценариев, когда SSD не имеет смысла, например телефон или киоск) не имеет никакого отношения к десктопам, никого не интересует.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует. Используй GTK, что ты как маленький.
По какой-то непонятной причине мир GTK не ограничивается. Но поскольку предоставлять декорации по запросу клиента мы не хотим, сделаем специальную библиотеку libdecor, которая по запросу клиента предоставит декорации. Теперь любое приложение, которое не использует популярный UI-фреймворк, должно таскать с собой этот костыль для Gnome.
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.
Смотришь в паспорт -- блин, я уже старый. Смотришь в трудовую -- блин, я ещё молодой.
Мир Линукс не в какой-то волшебной стране бесконечных ресурсов расположен. На что хватит сил из того, что наиболее востребовано -- то и будет поддерживаться. Остальное останется существовать в том виде, в каком есть, пока не устареет.
Грубо говоря дропнут поддержку X в очередном мажорном релизе фреймворка потому что тесты падают, а разбираться и фиксить их некому -- и все. Либо сам пили как хочешь, либо спонсируй, либо просто возьми уже свежую версию и не занимайся ерундой, вот и весь выбор.
Приложения перестанут его поддерживать целенаправленно. При использовании "чистых" Qt, GTK и т. п. все равно что за протокол используется, но полным-полно софта, которому надо или чуть больше, или что-то специфичное, или что-то, что в Wayland пока не реализовано, или просто X дёргает потому что ну он же у всех есть.
Так как Wayland стали ставить и включать по умолчанию, с этим софтом начнутся проблемы. Это криво, то не так -- эти проблемы будут исправляться с обеих сторон, что-то в приложениях, что-то в Wayland. В определенный момент окажется, что из всего дистрибутива XWayland не использует никто и его просто выключат. И вот тут можно будет сказать, что X кончился.
Ключевой момент текущих событий в том, что ещё недавно Wayland был сугубо экспериментальной штукой, которую надо было включать целенаправленно и обычно осознанно. Теперь наоборот это вариант по умолчанию. Если пользователь поставил свежую версию ОС и софт, а он глючит или не работает -- придется править. Чем больше будет исправлено и адаптировано, тем большей дичью будут казаться оставшиеся косяки.
X перестанут использовать осознанно, но его поддержка конечно останется ещё надолго. Только никому уже не будет до этого никакого дела.
Вообще я имел в виду прям вообще весь интерфейс. Не просто изображение какого-нибудь приложения, а прямо всё нутро UI, как это пытается делать X. Это сложно, это не всегда возможно и самое главное это никому уже толком не нужно -- любой клиент уже достаточно производителен, чтобы удаленный вызов самых различных функций по работе с условной кнопкой вместо передачи ее изображения был неэффективным и ненадежным кромчиловом.
Ваш сценарий работы довольно специфичен, но даже в нем X на самом деле не нужен. Ну, в смысле можно было бы сделать все то же самое и без X. Просто так вышло, что для X в силу исторических причин уже все есть, а для Wayland никто и не подумал делать.
Если будет спрос на чрезвычайно оптимизированный вариант проброса GUI окна или его части -- сделают и для Wayland. Но пока ситуация такова, что чаще всё-таки нужно пробросить рабочий стол или окно ровно как оно есть, со всеми особенностями и нюансами, один в один, и не морочить голову. Ваш сценарий работы может быть очень даже обоснован, но объективно ради небольшого количества человек никто не будет городить всю эту бесполезную канитель с выполнением GUI как будто это web-сервис какой-то на удаленной машине.
Ну и по конкретному сценарию работы. Вы же на локальной машине или хотя бы в локальной сети все крутите если я правильно понял. Зачем тут вообще проброс GUI? Локально есть просто монитор виртуальной машины, в локальной сети любой способ доступа к удалённому столу будет работать прекрасно. Более того, если окно виртуальной машины чем-то не нравится (я просто делаю его нужного размера и разворачиваю внутри окно нужного мне приложения в полный экран), то у VirtualBox и VMware есть seamless mode, который позволяет вытащить окно гостя на рабочий стол хоста.
Ну то есть это реально выглядит как решение проблемы, которой по сути и нет, а X это такой костыль, который чисто случайно подошёл.
Да, уровень поддержки X и Wayland сильно отличается. В одном будут править баги и добавлять современную функциональность, а во втором -- нет.
Приложения, которые не будут поддерживать Wayland, относительно скоро потеряют пользовательскую базу. Да, Wayland далеко не идеал, но X все. Можно сколько угодно сетовать, что в Windows 11 все плохо, телеметрия, кривое поделие с сомнительными решениями, и пытаться сидеть на вылизанной и стабильной XP -- но все, поезд ушел. Сидите сколько хотите, весь остальной мир будет жрать совсем другой кактус.
Qt, GTK и прочие фреймворки абстрагируют работу с элементами UI. Они предоставляют свой собственный API, а уж с использованием чего он реализован -- приложение, в идеале, знать не должно. В Linux они реализованы поверх X11 и, теперь, ещё и Wayland, в Windows -- поверх WinAPI, в macOS -- поверх Cocoa и т. д.
Qt это вообще один из наиболее популярных кроссплатформенных фреймворков для GUI, он в принципе не может работать только через X11.
Проблема комментариев, которые легко писать и поддерживать, в том, что они описывают что происходит, а не почему и зачем.
Что код/функция/модуль делает можно худо-бедно понять по самому коду. Куда важнее информация зачем вообще этот код нужен, почему код делает именно так, а не очевидно более простым образом и в каком направлении его можно менять, а в каком лучше не стоит -- пробовали, не получилось.
Но такие комментарии парой строк перед функцией уже не напишешь и такую информацию очень сложно поддерживать в процессе более-менее активной разработки.
Вот и получается, что описаний функций с аргументами полно, а логику и практики применения можно найти только в статье или вообще монографии опытного пользователя.
Соглашусь, утверждение было сформулировано слишком категорично.
Однако я имел в виду обычные, популярные протоколы доступа к удалённому рабочему столу, где не предполагается много видео. В таком случае старый добрый подход с как бы, типа, если один глаз закрыть, lossless передачей пожатых прямоугольников с изменившимися пикселями работает на удивление хорошо.
Хотя с современными кодеками, которые сами могут разбить кадр на произвольные области с индивидуальными параметрами сжатия, граница становится довольно размытой. Не удивлюсь, если к AV2 или H.266 проще и эффективнее будет тупо кодеком весь экран пожать с указанным битрейтом и не париться.
Вы вероятно плохо представляете, как сложен современный UI. Те "свистелки и переделки", которые навертели поверх того самого старого доброго X -- это уже неотъемлемая часть работы большинства приложений, от общей композиции рабочего стола до нормальных шрифтов и аппаратного ускорения.
Добрая часть UI уже давно не будет работать по сети в том виде, в котором это задумывалось в X изначально, часть вещей в принципе не может работать по сети и явно или косвенно опирается на предположение, что все локально. А худо-бедно прокидывается оно потому, что вместо высокоуровневых примитивов там передаются целые области изображения -- как в VNC (а не VPN, надеюсь вы просто опечатались), только криво.
В итоге "как задумано" оно работает только в примитивных сценариях, которые нельзя назвать общим решением. Либо оно работает так же, как и остальные протоколы, только ещё и X там ни к селу, ни к городу.
Справедливости ради, касаемо окон и пр. WinAPI это будет аналог оконного фреймворка, например того же GTK.
Если бы Linux мог себе позволить иметь один единственный официальный фреймворк для GUI, было бы намного проще.
И какое это имеет отношение к вышесказанному?
Во-первых, видео а-ля стриминг игр нигде и не перекачивается, ни в плохом качестве, ни в каком.
Во-вторых, если ни один из этих протоколов не работает если связь меньше мегабита, ну значит для этой задачи объективно надо мегабит.
X просто не подходит, даже если он по тоненькому каналу может работать. Если "не передавать контент вне оконных примитивов", ограничившись только чистым X, то это будет работать только с X, то есть в довольно ограниченном виде. Если вам хватает простецких окон терминала и блокнота с древними шрифтами -- прекрасно, остальному миру не хватило. Если же прокинуть через X десктоп с композицией, а в нем ещё и современный браузер, то там уже по сути VNC начинает ходить, то есть все те же копии картинок.