Легкий Х терминал
dnk 25 ноября, 2014 - 22:11
Задумка поставить жужжащую винтами и вентиляторами машину куда в чулан, а на стол маленькое легкое и бесшумное с единственной задачей вывода экрана и звука с "большой".
Первая идея постаить X-server и запустить KDE(любимый десктоп) с большой (Gentoo, но думаю неважно) на нем. Сказано сделано. Воткнут arch linux, Xorg, заходим по ssh на большую , делаем export DISPLAY=IP:0.0 ; startkde
Тут что-то пошло не так. KDE стартует, но:
1. сразу сообщает, что отвалились звуковые устройства т.е. звука не будет.
2. панели нет. Ее можно добавить, но настораживает. При запуске локально на большой панель есть сразу.
Что я делаю не так? К сожалению валом статей как затуннелить через SSH, но мне туннелить в локалке 100Мбит зачем?
»
- Для комментирования войдите или зарегистрируйтесь
Если не ошибаюсь, со звуком
Если не ошибаюсь, со звуком все программы работают напрямую, без участия Х сервера. Так что для выдачи звука на локальном компе программа должна быть тут же.
Впрочем, я в этом деле не эксперт, могу и ошибаться.
Чем больше юзерфрендли, тем сложнее юзать.
xpra + openssh с USE=hpn
xpra + openssh с USE=hpn можно запустить без криптографии (только при аутентификации).
И можно через XDMCP запускать. А так конечно надо осваивать overlay LTSP.
так, во первых отвечу самому
так, во первых отвечу самому себе.
1.Для корректной работы KDE нужно на Xserver использовать его родной оконный менеджэр kwin
2.Для звука нужно установит и настроить pulseaudio на Xserver (терминале)
Так-что все работает теперь но МЕЕДЛЕНННООО. Неясно почему, но есть подозрения на отсутствие VDPAU на стороне терминала.
В общем да, уже нарыл LTSP и начал читать. Пока не понял в чем цымес, обещают нормальную работу на полной рухляди. Про xpra почитаю тож, спасибо за наводку
>>обещают нормальную работу
>>обещают нормальную работу на полной рухляди
Правильно обещают. Но именно "нормальную работу". Музыка и видео, новомодные трехмерные свиристелки для рабочего стола в понятие "нормальная работа" , к сожалению, пока не входят. Чисто теоретически картинка, сформированная на мощном сервере должна каким-то образом быть передана на клиент. Я подозрреваю, что современные размеры мониторов, а так же глубина цвета несколько громоздки даже для гигабитного сетевого соединения. Проверить достаточно просто - посмотреть одним глазом фуллхд видео, вторым косясь на загрузку канала через какой нибудь iptraf-ng, к примеру.
Грубая прикидка не очень хорошего монитора с 32 битным цветом при 25 кадрах в секунду дает постоянный поток приблизительно в гигабит (1280*1024*32*25=1048576000). Понятно, что кадры можно пожать, потом разжать но.... Эффективных алгоритмов быстрого и качественного сжатия и ( при условии возможности такого же быстрого разжатия на стороне клиента), насколько мне известно, не существует.
wi написал(а): >>обещают
ну, будет нормально если экран не будет волной перерисовываться при перетаскивании окошка например. Передачу изображения тупо как есть уже давно не практикуют. А так-то именно в этом вопрос "какой наиболее легкий клиент с разумным протоколом передачи для линукс" Для виндовс это RDP. Причем смешно, что клиенты зачастую именно линуксовые. А вот аналога для линукс-линукс нет или я его не знаю.
LTSP ковыряю помаленьку. Проблема в том, что gentoo его не поддерживает, ltsp оверлей откровенно заброшен.
Плюс у самих ltsp отсутствует внятная документация по организации сервера и клиента. Отсылают к реализациям в дистрибутивах. В апстриме даже банального readme нет. Кое-как нашел, что они вроде-как используют тоннель X -ssh. Как будет время проверю туннель, может быстрее чем голый X. И с другого конца попробую в виртуальной машине воткнуть сервер на базе Ububntu, там говорят работает, чтоб посмотреть чего они там мутят.
Хорошо что вы вспомнили про
Хорошо что вы вспомнили про RDP, отметив его как лучший в своем классе. В протоколе RDP несколько лучше реализовано сжатие, за счет передачи только части изменяемого скрина. Все это прекрасно работает на офисных приложениях. Но... Тест достаточно простой. В терминальной сессии запустите просмотр видео на фуллскрин. Программка iptraf-ng развеет все ваши сомнения относительно передачи рав видео по сети. При этом вас не должна смущать возможность онлайн просмотра (при наличии толстого канала) правильно пожатых фуллашди фильмов с шары. Потому что файл фильма предварительно сжат по ассиметричному алгоритму, то есть на сжатие фильма заранее потрачено значительное процессорное время, что позволяет реально снизить прокачанный объем. Распаковка, благодаря ассиметричности, высоких затрат на процессор и подсистему ввода-вывода не требует. Быстро и качественно запаковать рав (коим по сути является вывод на экран) не представляется возможным. Да, ваша идея по поводу убунту на виртуальном сервере, не выдерживает никакой критики по выше указанным причинам. Во-первых поток есть поток (и его к сожалению некуда девать). А во вторых связь виртуалки с клиентом скорей всего пойдет по VNC (spice имхо чуть получше, но тоже не блещет). А лстп это всего лишь способ сделать бездисковый клиент, который будет либо делать все сам (на своем камне), либо заюзает иксы удаленного сервака напрямую или через vnc/rdp/чтолибоеще со всеми вытекающими. Так что без сетки ниже 10G не пойдет.
По этой же причине эмулятор, запущенный локально и выводящий свое видео напрямую на скрин хоста значительно шустрее (по видео выводу разумеется) нежели тоже самое, запущенное удаленно и выводящее картинку через внц.
если чулан в пределах 20м -
если чулан в пределах 20м - то хватит и HDMI кабеля к монитору и активного USB2.0 удлинителя с хабом на конце для клавиатуры, мыши и подключения флешек.