Pull to refresh

Comments 144

Qt прекрасно поддерживает directFB и в общем то может быть портирован на любую оконную систему. А у Иксов проблема, что там слишком много всего, что-то отмирает, что-то опять нарождается. Вот новая спецификация трея в принципе хороша, но она потеряла сетевую прозрачность. Хотя наверное добавить в DBUS сетевую прозрачность вполне выполнимая задача.
> сетевую прозрачность

а оно реально нужно? что-то я давненько не слышал о реальных применениях этой штуки.
видимо нормального ответа, кроме минусования, не дождусь. сдается мне, никто и не знает зачем нужна сетевая прозрачность :)
Насколько я знаю (не очень хорошо, немножко только) x11 разрабатывался именно как сетевой протокол. Стоит у вас сервер и показывает окошечки, а клиент (сами программы, которые что-то там делают) — где-то далеко. Сейчас и то и другое обычно стоят на одном компьютере и про то, что это сетевой протокол, все начали забывать.
А ведь удобно же было бы иногда — запустить удаленно программу и наблюдать ее работу у себя на экране.

Ну так вот DBus — он работает на клиенте и про сервер ничего не знает, наверное, вот и вся проблема.

Если говорю неправильно — поправьте, пожалуйста :)
я знаю про клиент-серверную архитектуру иксов. но, во всех популярных дистрибутивах линукса X запускается с ключиком -nolisten tcp, а коммуникация между сервером и клиентом происходит через сокеты. более того, в 99.9% случаев это и не нужно. ради 0.01% тащить значительный overhead?
а запускать удаленно программу можно (и нужно) через ssh X forwarding.
DBus практически никаким боком к X и не пристегивается, это совсем другая штука, предназначенная для коммуникации между приложениями.
я не очень в теме, а ssh x forwarding — это не то же самое, только через ssh?
а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
> а ssh x forwarding — это не то же самое, только через ssh?

нет, X forwarding — это запуск приложеня чрез ssh туннель. а та штука которую мы обсуждаем, нужна для организации удаленной X сессии.

> а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?

нет, там хотят сделать отдельный протокол для трея.
см. standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
буду знать, спасибо за пояснения
как будто ssh X forwading форвардит UNIX сокеты, а не tcp пакеты
там совсем другой механизм работы, для него совсем не нужна вышеописанная прослойка.
И какой? Такие же сокеты просто проброшенны через ssh.с Сетевая прозрачность нужна, другое дело что не нужна половина классического X11 давно уже не нужна т.к. используются расширения вроде xft и xrender.
> Сетевая прозрачность нужна

нужна в очень редких случаях. почему-бы не сделат её хотя-бы отключаемым модулем?
А мешает? Пакеты так или иначе нужно сериализовать/десериализовать, не важно через что отправляя, через сокеты или через shared memory.
лишнее время/ресурсы гонять данные через сокеты.
мне кажется, сетевая прозрачность для Х уже не так актуальна. На деле Х форвардинг работает криво и тормознуто. Приходится искать альтернативы в виде NX
со стороны клиента — tcp, со стороны сервера — локальный сокет.
> а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?

хотя, возможно, что-то такое в DBus и делают, но это уже не на уровне иксов, а выше, DE/WM.
В технологии X сервером называется клиентский терминал. А клиенты в терминологии X — это приложения, которые запущены на удаленных машинах (множественное число, обратите внимание). То есть ваш терминал (то бишь X-сервер) может отображать окна приложений исполняющихся на разных машинах находящихся в разных концах земного шара.

Что по-вашему в этом случае должен отображать системный трей? Или каждая удаленная машина должна вам в рисовать свой собственный системный трей?

На каждой из этих машин ведь может быть запущен свой dbus. Про сеть dbus ничего не знает, не говоря уже о том, как передать сообщение в ваше приложение в соседнем окне, которое исполняется на другой машине… Надеюсь так понятней должна быть проблема…
да, забыл добавить. клиент-серверная архитектура разрабатывалась когда в моде были большие мейнфреймы и терминалы.
Так сейчас облака и тонкие клиенты снова становятся модными.
Так что клиент-серверная организация — это тру.
Если все происходит в одной сети организации, то ssh будет лишней тратой ресурсов.
В декстоп-ориентированных дистрибутивах, действительно, имеет смысл по умолчанию отключать сетевое взаимодействие. Однако лет 5 назад, на семинарах по информатике, я очень любил коннектиться с учебного компа на свои домашние иксы и работать на них. Свои настройки, удобно.
оно нужно в очень редких случаях. зачем тащить на десктоп клиент-серверную архитектуру иксов если она фактически не используется как задумано но таки вносит свой overhead? а для облаков и прочих тонких клиентов есть более эффективные решения.
Если создавать новые несовместимые протоколы, то будет полный зоопарк графических оболочек. Гном под иксы, гном под DBUS; Кеды под гном и под DBUS и т.д. А потом кто-нибудь придумает еще что-нибудь, и нужно будет создавать новую ветку оконных менеджеров. При этом фичи из одной ветки в другую будут попадать не сразу, и прочие радости от кучи стандартов. Да, а еще разработчикам программ, наверное, тоже надо будет писать кучу лишнего кода для каждой из версий. Плюс в подарок потеря совместимости.
Нафиг-нафиг.
С моей точки зрения вполне логично просто на десктопах отключать сеть, как это происходит сейчас.

К тому же, тут еще вопрос, кто важнее: 1000 юзеров десктопов убунты, или меньшее количество пользователей компании с 1000 компами, которые используют эту фичу в своей работе.
Много там проблем. В какой-то момент отказались от задания шрифтов в X-сервере. Теперь при работе по сети на сервер летят картинки с отрисоваными буковками вместо команды «написано ААА шрифтом БББ». Требования к сети кардинально возросли.
Мне нужна, регулярно иксы по сети использую.
а на самом деле в энтепрайзе vnc и запуск иксовых приложений сквозь сеть распространены повсеместно.
vnc кидает картинку экрана. с сервера на клиента.
это совсем не то, что команды отрисовки.
вот только на текущий момент почемуто проброс, например, браузера, через инет работает в разы медленнее чем просмотр растровой картинки через vnc :(
А текстовые интерфейсы через ssh работают ещё быстрее. ;)

Это вина тулкитов. Сравните kpdf и xpdf через сеть.
терминал серверы.
ltsp.
eubuntu.

там и без того с сетью уже не так все хорошо. недавно пробовал krusader запустить и он крашился непонятно почему. старый трюк с export DISPLAY= уже недостаточен.
Спасибо за комментарий!
помнится, запускал я на маке какой-то софт, работающий из-под иксов.
(Х11 в макоси сразу есть)
это такой страх и ужас и нереальный тормоз, что мозгой двинуться можно…
нету там Х11, там огрызок от него какой-то. Если попробуете настраивать NX, к примеру, то поймете.
Согласен. Все Х программы выглядят как-то совершенно инородно, и работают с тормозами и глюками.
Как всё страшно… Блин, а это даже не Windows с его костылями в WinAPI…
Можете привести пример костыля WinAPI?
Спасибо. Я и не думал что всё так страшно.
все еще страшнее. man xorg.conf:

VIDEOADAPTOR SECTION
Nobody wants to say how this works. Maybe nobody knows…

Пробовал писать на XCB оконный Hello World с часиками: это же ужас какой-то! Во-первых, объем кода больше, чем тот же случай на Xlib, раза в два-три. Более того, вменяемой документации по XCB нет. Даже официальный мануал написан очень и очень поверхностно.
Остается качать исходники и заглядывать, анализировать… И после этого обвинять тулкиты в несоответствии стандартам уже как-то не особо и хочется — во имя результата все средства хороши, особенно если они преподносят его на блюдечке. Уж на тот же Qt я по части документации ругаться точно не буду… Не говоря уже о всяких прелестях вроде QtCreator и т.п.
Согласен, именно внимания к деталям, не хватает многим хорошим проектам. Qt одной только качественной документацией способна прельстить программиста, уставшего от ковыряния разрозненной информации в сети. И пока у XCB не будет более дружественного лица, не появится и мощного сообщества. А жаль…
А в чем проблема насильно портировать Qt и GTK+ на XCB, убрав поддержку Xlib, помимо лени? Ведь подавляющее большинство программ пользуются лишь возможностями тулкитов.
Но что GNOME, что KDE, скорее всего, придется переписывать чуть ли не с нуля.
Проблема в том, что это лишь мнение одного человека — автора awesome. Вот пришел он, сказал, условно, что Xlib — какашка, а XCB — это очень круто. Придет другой человек, скажет, что Xlib — нормальная, культурно написанная, поддерживаемая и документированная библиотека, а XCB — поделка двух с половиной студентов с неудачным API, плохо документированная и вообще глючащая через раз. И кому верить?

Поставьте себя на место разработчика GTK/Qt. Например, XCB есть сильно не везде. В дистрибутивы оно массово начало вливаться в 2005-2006. Кое-где его до сих пор нет. Сейчас можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения. Менять шило на мыло (о чем, кстати, и говорит автор awesome) с приобретениям какого-то количество явных минусов и небольшого количества эфемерных плюсов, видимо, далеко не все хотят.
> можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения
Не заработают :)
Новый Qt/GTK+ требует новый glibc, новый glibc требует новое ядро и далее по списку.
правда? а почему же последний Qt собирается до сих пор с древними gcc?
или мы путаем своместимость бинарную и на уровне исходников?
Только вот вчера собрал Qt 4.5.2 c gcc 2.95 на ядре 2.4.22
Осталось пропатчить KDE… ©
шутка помоему про FreeBSD была, а не про Linux :)
Xlib объективно проигрывает по скорости XCB за счет своей модели запросов. Сверх того, в XCB вся соль в наличии у многих действий, единиц идентификаторов — многопоточный код наворачивать гооораздо безопасней.
Мне кажется, что слово pager, в баге ООо, в русском переводе должно звучать не совсем пейджер, но, черт возьми, не видно для него другого перевода, как и для еще нескольких слов:(
Я прошёлся по паре ссылок и нашёл определение слова pager в стандарте EWMH:
A pager offers a different UI for window management tasks. It shows a miniature view of the desktop(s) representing managed windows by small rectangles and allows the user to initiate various window manager actions by manipulating these representations.


То есть, это область, в которой рисуются миниатюры окон с рабочих столов (в виде прямоугольников). В XFCE и GNOME эта область назывется "Переключатель рабочих мест". Пожалуй, так и переименую. Надо было проверить это ещё при переводе. My fault :)
Тогда уж «рабочих столов»
а что за пейджер такой?
Было «OpenOffice в качестве пейджера», с ссылкой на другой пост того же автора.
Можно заметить, что Х — не единственный неидеальный протокол. Все знают семиуровневую модель OSI, но вот статья о самой OSI:
en.wikipedia.org/wiki/Open_Systems_Interconnection — English
ru.wikipedia.org/wiki/Open_Systems_Interconnection — Русский
OSI дал плоды в теории и совсем новых протоколах, но была у них и попытка заменить неидеальный TCP/IP чем-то новым более гибким, а для замены совсем тупого SMTP предлагался монстрик X.400. Иксам по сложности ещё очень далеко до какого-нибудь HTML/CSS, так что путь эволюции ещё по-видимому не исчерпан. Хотя конечно, революции бывают.
Если покопаться, можно найти очень древнее решение, определяющее сегодняшний IT. Ну, все знают по ускоритель шатла и двух римских лошадей.
«Конструкторы многоразового космического корабля „Кеннеди“ не могут увеличить мощность его ускорителей, потому что их диаметр (1,524 м) определяется… шириной лошадиного крупа».… Каждый из двух твёрдотопливных ускорителей американского «Шаттла» имеет длину 45,7 м и диаметр 3,7 м (в районе топливных сегментов двигателя). Наружный топливный бак, который содержит криогенное топливо для питания маршевых двигателей «Шаттла», имеет диаметр 8,4 м. Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому туннелю. Расстояние между рельсами стандартное: 4 фута 8,5 дюйма (1,435 м), поэтому конструкторы могли сделать двигатели только шириной 5 футов. Вопрос: почему расстояние между рельсами 4' 8,5"? Откуда взялась эта цифра? Оказывается, железную дорогу в Штатах строили такую же, как и в Англии, где, в свою очередь, железнодорожные вагоны делали такими же, что и трамвайные, а первые трамваи производились по образу и подобию конки. А длина оси конки составляла как раз 4' 8,5".

Но почему? Потому что конки делали с таким расчётом, чтобы их оси попадали в колею на английских дорогах – благодаря этому колёса меньше изнашивались, – а расстояние между колеями в Англии как раз 4' 8,5"! Отчего так? Да просто дороги в Великобритании стали делать римляне, подводя их под размер своих боевых колесниц, длина же оси стандартной римской колесницы равнялась… Правильно, 4' 8,5"!

Первые колейные дороги Древней Греции и Древнего Рима, представлявшие собой углубления до 50 мм в каменном основании, имели ширину 1,5–1,6 м. Это соответствовало ширине уличных экипажей.

Ну вот, теперь мы поняли, откуда взялся этот размер. Но всё же, почему римлянам вздумалось делать свои колесницы с осями именно такой длины? А вот почему: в колесницу запрягали обычно двух лошадей.
А 4' 8,5" – как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы её равновесие. Суммарная ширина крупов двух лошадей намного больше длины оси колесницы.
отсюда
У HTML/CSS вообще баг by design. Они описывают статический контент, а от них хотят динамического.
Если бы в шестидесятых годах прошлого века разработчики SGML из ну очень важной компашки IBM только знали… Если бы только знали… :)
UFO just landed and posted this here
Не распарсил про directFB… Сейчас эта штука в общем то к линуксу гвоздями прибита, там есть серьезные проблемы с I/O драйверами, точнее приходится много плясать, иксы в этом плане хорошую абстракцию дают. Код XInput хорошо бы оставить в любом случае. Вообще по хорошему можно весь рендеринг клиентский на openGL перевести, а его инструкции по отрисовке по сети гонять. Скоро уже все свободные драйвера точно будут уметь openGL аппаратно. Что-то такое как раз в Wayland'е предлагают.
триста раз сказано — X-протокол это не только графика, но и управление (окна, кнопочки, иконки, трей,… ШРИФТЫ наконец, про которые уже все давно забыли и гонят битмап), клавиатура, буфер,…
>В итоге опять кучу времени тратим над настройку над Х
Кто тратит? Уже давно всё в тулкитах есть, старые API протокола никто не использует, просто болтается исторически.
>Лучше уже занятся Wayland
Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
>Или уж directFB, там не плохая портированость, а не желания производителей видеокарт под него делать свои драйвера и карты.И есть не адекватная поведение и эффект зеленного экрана.
Так сейчас все опенсорсные драйвера в ядро переезжают, правда я не знаю юзает ли directfb dri. Кстати, разве directfb не linux-only?
>Еще можно рабочее окружение и т.д в полном opengl,openal и opencl отриосвать и сделать, ресурсы позволяют для современных ПК, так извращатся, даже рабоать именно только через них и sdk
Да, EGL/OpenGL/OpenVG было бы круто. Но всё равно помимо EGL ещё нужен слой для управления окнами и воодом.
> Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
Если над ним будет работать один Кристиан — то да. Если же люди, которых этот перевод должен был мотивировать заняться X12, вместо этого помог разработке Wayland — всем, я полагаю, будет лучше. Поправьте меня, если я ошибаюсь.
Из этой статьи я не уяснил для себя одного — почему же у графического интерфейса X11 такая низкая производительность. Интерфейс Windows XP с его убогим GDI уделывает юникс приложения в пух и прах (и это заметьте без всяких там композит манагеров).
Выходит, что не таким уж и убогим.
У GDI другая убогость… Хотя он да, быстрый ибо таки в ядре.
«Убогий набор инструкций процессора RISC» :D
Убогий он потому, что в ядро вбит. Очевидно же)))
при использовании всевозможных расширений типа EXA ни сколечки не уделывает по производительности, но вот разработчики проприетарных драйверов как-то через жопу эти расширения юзают.
Зато виндовый ремоут десктоп это фейл.
Я в подробностях реализации не разбираюсь, но за счёт его синхронности и, видимо, за счёт упомянутой вшитости в ядро он может любой мощности сервер затормозить капитально когда ремоутная сессия по медленному каналу идёт (а если это веб сервер под нагрузкой то канал полюбому занят будет).

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

Я как мог описал это в своём блоге (на английском) + пруф видео какое-никакое состряпал — mvmn.wordpress.com/2010/02/11/microsoft-rdp-protocol-a-failure/ — но опять же я в технических деталях не разбираюсь, потому особой информативности не обещаю.
А для Vista/Win 7 подобная проблема характерна?
Не знаю, я пробовал 2003-й сервер, но тот кто рассказал мне эб этой проблеме испольщовал 2007-й сервер насколько я помню, так что подозреваю что и Виста и 7-ка работают так же.
ничего что msts едва ли не единственная реализация со вменяемой работой с сессиями, да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы, внц и тому подобный «свободный» шлак.

при желании все няшки винды и ад вполне на ок крутятся из консольных утилит. другое дело что sshd в коробку не положили, это да, печально. а насчет каналов, я уж не знаю какие у вас каналы там, но вот кстате особенно заметна разница между рдп и всем остальным именно на узких каналах. вы бы попробовали в mstsc или в вашем любимом rdesktop'е выкрутить гайки цвета и настройки оформления со стороны сервера в минимум. даже на 256 килобитах с ~1-2 секундной задержкой msts отрабатывает вполне сносно. вот уж чего не скажешь о vnc и прости господи лядского X11.
> ничего что msts едва ли не единственная реализация со вменяемой работой с сессиями,
> да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы
Не знаю так ли это, не имел много возможностей проверить, но по части сесий у RDP уже коммерческая проблема, ибо за сессии приходиться платить, а для не серверных версий так вообще нельзя иметь больше одной сесии — на моих виндах нельзя сидеть за компом одновременно прямо и ремоутно, хотя и версия профешнал а не хоум.

Про тормозные аплинки тоже както не уверен. По крайней мере под Х-ами это не заставит тупить сам сервер, вот и радости. Ну и ясно что главное преимущество линухов и т.п. — возможность более чем адекватного администрированя через терминал. Под виндами же без GUI никуда. Может сами они и ок с консольными утилитами (что тоже не правда), всёравно из сторонних вендоров никто не пишет апликух под винды способных адекватно работать через консоль.
Я даже не знаю можно ли адекватно IIS админить через консоль — подозреваю что нельзя.

Насёт каналов, я уже упоминал что сам канал может быть вполне адекватным, но т.к. сервер то в продакшне и под нагрузкой то скорость сети может быть достаточно низкой.
не надо подозревать, надо открыть и прочитать. IIS можно управлять через его вебморду http(s), так же в IIS 7.0 есть powershell с плагинами для его управления, а еще есть appcmd.exe, — тулза для управления IIS'ом из консоли. вот так-то! альтернатива для msts есть. :)

не представляю каким образом ожидание телодвижений со стороны mstsc заставит «тупить» рабочие задачи. или у вас рабочие задачии в фореграунде в пользовательской сессии? ну тогда msts тут не причем. к слову о рабочих задачах в сессиях, по сей день единственным вариантом тюнинга 1С для работы с большим количеством клиентов по-прежнему является работа через msts (да, еще использования *SQL бакенда, ну да это не суть важно).

у микрасофта в серверных приложениях есть несколько интерфейсов взаимодействия, нынче гуи, павершелл, вебморда и какая консольная тулза. возможно не у всех приложений есть полный набор, но альтернатива есть в любом случае. насчет сторонних программ ничего не скажу, не особо ими пользовался, может быть тут вы правы.
не кормите тролля :)
Хорошая статья. А главное, это ведь основа, без которых немыслима работа с UNIX на desktop'е. Надеюсь кто-нибудь найдет в себе силы и перепишет всё как следует.
Ну да. Именно такие мысли и сподвигли меня сесть и потратить пару вечеров на перевод. Статья-мотиватор.
UFO just landed and posted this here
Дело в том, что X11 это не только сокеты, он также умеет работать и через shared memory, dbus же на сокеты завязан. К примеру в android там тоже весь управляющий трафик по их IPC гоняется (сраный binder), но буферу куда изображения рендерятся лежат в shared memory (кстати у них на это тоже свой велосипед).
Спасибо за перевод! Читал статью в оригинале ещё давно, понял что X11 — самая ужасная и уродливая часть современного Linux-десктопа. Хотел сам написать такую статью, но руки не доходили.
X11 must die.
UFO just landed and posted this here
В идеале что-то вроде Wayland. Весь рендеринг окна client-side, напрямую в графические буферы, а графический сервер занимается только смешиванием всех буферов в окончательную картинку. Жаль, что Wayland пока не особо шевелится.
UFO just landed and posted this here
Шевелится. Пару месяцев назад Кристиан сменил OpenGL на OpenGL ES. К Qt помаленьку прикручивается поддержка Wayland: cgit.freedesktop.org/~jbarnes/qt-wayland/?h=4.7
Интересно. А как вы это нашли? Есть какие-то ссылки на записи в блогах, или что-то такое? (я про branch Qt для Wayland)
Не помню точно. Кажется, на форуме Фороникса эта ссылка была в обсуждении одной из новостей, посвящённой Wayland.
Но это не значит, что иксы не должны сдохнуть в муках.
Да чтоб тебя. А заменять чем будем, когда умрет?
Die то не надо, а то будем тогда в черных терминалях сидеть, потому-что адекватных замен нет. Другое дело что надо, перерабатывать то что есть. Нужно пересматривать протоколы, переделывать библиотеки и API. Подстраиваться под сегодняшние реалии, добавлять нужное и что важнее избавляться от ненужного, даже если это иногда плохо сказывается на обратную совместимость.
«Кроме того, я думаю, что X11 должен быть разрушен.»
То-то у меня при любом движении мышкой использование CPU подпрыгивает резко… На процесс X уходит… А альтернатив то нету! (
UFO just landed and posted this here
блин, на самом деле. Думал, только в ХР так.
ну, включите аппаратную мышку, чтоли…
Расскажите плз поподробней, что за зверь?
Option «HWCursor» в разделе «Device»
Тем кто реально толкает линуксы в массы (большие корпорации, да?) иксы не нужны, так бы уж давно собрались, договорились и написали.
А так и получается, все, кому всерьез нужен графический интерфейс поверх UNIX-OS (не берем серверные применения) рисуют что-то свое, отличное от X-Window System. Как пример — MacOS X и Android.
никакие большие корпорации линуксы в массы не толкают, а толкают они на рынки серверов, где GUI то и не особо нужен
Есть мнение, что это так и не сдвинется с мертвой точки до тех пор, пока это не будет нужно кому-нибудь типа Google для чего-нибудь типа GoogleOS.
А что мешает им на каком-то этапе развития своей ОС это изменить?
Зря по вашему делают KMS+DRI2? Они как раз позволяют от иксов отвязаться
Напомнили про ICCCM. В нём содержится небольшая и игнорируемая «современными» DE (альтернативы которым умрут по мнению автора) заметка. Сервер имеет право отказать в изменении размера окна, и клиент должен рисоваться в той клиентской области, которую ему дадут. Программки вроде XMMS и половины модулей Gnome и KDE это игнорируют, чем создают большие проблемы при использовании фреймовых WM'ов. Сейчас в GSoC вроде появился проект по добавлению фреймового режима в kwin, может и клиенты начнут чинить.
Месье Жульен, видимо, не знает об Икс-Сервере Попова
Вы серьёзно считаете своё выссказывание смешным или остроумным?
конечно (я думал, это очевидно)
Качественный и интересный перевод. Спасибо. /*грустно вздыхает*/ Побольше-бы такого контента на хабр.
а как-же QWS как альтернатива? Конечно сейчас это достаточно примитивно — но как минимум KDE на QWS можно запустить, а он в свою очередь может работать и над иксами и над DirectFB и напрямую с видеодрайвером. Очень универсально. Я думаю в таком направлении нужно двигаться.
И получить пляски с устройствами ввода, это основная трабла фреймбуфера.
UFO just landed and posted this here
а можно ссылку на вьювер? PPA для lucid есть? ))
UFO just landed and posted this here
ppa — это репозитарий с программой для убунту на ланчпаде.
UFO just landed and posted this here
это чтоже…
«системный трэй» не работает для удалённых клиентов по сети?

неправда, однако.

под кубунтой-9.10 kde-4.3 ltsp-5
на терминалах регулярно (из-за сброса настроек) всплывают уведомления типа
«аудиокарточка %название_аудио_насервере% не работает, переключаюсь на pulsaudio»
тоесть уведомление с сервера отрисовывается на терминале, подключённому по tcp.

что я делаю не так?
Отрисоваться-то он отрисуется — его же иксы рискуют (само сообщение). Вопрос в том, на каких рабочих столах и у каких пользователей :)
ну, с двумя сессиями от одного пользователя даже локально нифига не работает.

а насчёт десктопов вроде всё нормально.

но надо бы проверить.
есть какой-нибудь стандартный способ создать уведомление в kde?
kdialog --passivepopup отрабатывает на правильном, терминальном десктопе.
другой эксперимент:
флэшка вставляется на сервере и на терминале (пользователи разные),
оповещения о ней появляются вполне корректно.

чисто по опыту, без ртфмства:
либо информация о dbus не верна/устарела,
либо на практике в ltsp используются какие-то хитрости.
И снова попытки делать супер-пупер универсальный велосипед…
Какие-то намёки на OpenGL для удаленных клиентов…
Что за дикость делить систему по библиотекам а не по функционалу?
ЧТо мешает выделить три уровня — аппаратный (отрисовка). Есть не плохой пример — модель DirectX. Сделать тоже самое на OpenGL (собственно уже есть) + аналог DirectInput.
Поверх прикрутить менеджер рабочий столов.
А уже по верх прикрутить удалённый рабочий стол.
Зачем парить мозги попытками передать OpenGL по сети? Это не тот уровень и не та задача. Гнать нужно уже уровень окон.
И будет замечательная структурированная быстрая и логичная система.
А проблема, кстати, характерна для большинства Linux — софта. Софт разрастает, никто не хочет править старое и никто не хочет документировать — все хотят писать новое. Расширения плодятся. И стоит заикнуться о том что код превратился в болото, что нет не то что документации, а даже способа её получить, так как разработчики ушли, и никто кроме них в недокументированных фичах и настройках не разбирался, что структура проекта утеряна на прочь и он полон взаимопротиворечиых расширений, как поднимается вонь до небес! Начинаются вопли о совместимости столетного оборудованния и софта (и что, из за того, что кто-то где-то использует старьё, весь остальной мир должен довольствоваться тормозами и глюками.
Начинаются истерики по поводу портирования 1% расширений, которые использует 1% пользователей. И им насрать, что есть более новые и логичные расширения — не переписывать же им свой 1% кода?! Нет. Пусть все остальные тянут с собой это болото.
А уж какие крики о неподъёмной трудоёмкости… Видите ли нужно обязательно тянуть с собой всё болото и тестировать ена вековом оборудовании.
А большая же часть аргументов сводится к тому, что «работает, ну и ладно — на наш век хватит, а там разберутся».
Одно ядро достаточно взять… Вместо того, чтобы разработать/переработать/документировать стандарт на модули драйверов видеокарт все с крим ура лезут голой жопой на кактус и ратуют за их включение непосредственно ядро. Получается чёрный ящик в чёрном ящике. И никто не думает о том, кто и какими силами потом будет тянуть всё это болото по мере увеличения разнообразия видеокарт.
Короче, говоря — иногда демократия это плохо. И для мира *nix наступает именно такой момент. Корпорации и производители закрытого софта могут волевым решением сменить архитектуру, выкинуть лишнее, изменить идеологию, заставить пользователей обновить железо. Да, каждый раз вопли, слёзы и сопли, но тем не менее это избавляет от мёртвого кода и не нужно совместимости.
В общем, я лично категорически не понимаю, какой будет выход у сообщества открытого софта.
фразой «гнать уровень окон» вы имеете ввиду передавать по сети уже отрендерёные картинки целых окон?
3D ваще очень капризная и требовательная штука и для хорошей работы количество слоев больше чем ядро-дрова-OpenGL неприемлемо впринципе. Попытки наложить сложную графику на клиент-сервеную архитектуру — так вообще срамота на костылях. И вместо того, чтобы переработать и все оптимизировать по человечески, все придумыывают новые костыли пверх сущестующих, а поверх этих еще одни, и еще и еще.

Я считаю что графическую систему(иксы в данном случае) надо делать одним цельным куском без разбиения на клиента и сервера.
к иксам цельным куском придётся приделывать костыли для терминал-серверных решений.
Но тогда это будет костыли-опция, а не костыли-по-умолчанию, которые тебе не нужны, но они есть и от этого все работает не так хорошо как мого бы.
ну в принципе, да.
так логичнее.
Спасибо автору.
Ситуация из последнего абзаца показательна не только для X-ов, но и для большинства продуктов с долгой историей.
UFO just landed and posted this here
Благодарю за труд, статья из разряда очень интересных.
Дык это, давайте популяризировать проблему, писать на ЛОРах о ней, на Опеннетах, в уютненьких жж-шечках, итд. И все это с лозунгами мол набираем девелоперов. И потом к получившемуся шуму можно за нос притянуть тех же девелоперов X11 и KDE и Gnome. Ну, это в теории.
Sign up to leave a comment.

Articles