Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 144
интересная статья, спасибо.
Qt прекрасно поддерживает directFB и в общем то может быть портирован на любую оконную систему. А у Иксов проблема, что там слишком много всего, что-то отмирает, что-то опять нарождается. Вот новая спецификация трея в принципе хороша, но она потеряла сетевую прозрачность. Хотя наверное добавить в DBUS сетевую прозрачность вполне выполнимая задача.
> сетевую прозрачность
а оно реально нужно? что-то я давненько не слышал о реальных применениях этой штуки.
а оно реально нужно? что-то я давненько не слышал о реальных применениях этой штуки.
видимо нормального ответа, кроме минусования, не дождусь. сдается мне, никто и не знает зачем нужна сетевая прозрачность :)
Насколько я знаю (не очень хорошо, немножко только) x11 разрабатывался именно как сетевой протокол. Стоит у вас сервер и показывает окошечки, а клиент (сами программы, которые что-то там делают) — где-то далеко. Сейчас и то и другое обычно стоят на одном компьютере и про то, что это сетевой протокол, все начали забывать.
А ведь удобно же было бы иногда — запустить удаленно программу и наблюдать ее работу у себя на экране.
Ну так вот DBus — он работает на клиенте и про сервер ничего не знает, наверное, вот и вся проблема.
Если говорю неправильно — поправьте, пожалуйста :)
А ведь удобно же было бы иногда — запустить удаленно программу и наблюдать ее работу у себя на экране.
Ну так вот DBus — он работает на клиенте и про сервер ничего не знает, наверное, вот и вся проблема.
Если говорю неправильно — поправьте, пожалуйста :)
я знаю про клиент-серверную архитектуру иксов. но, во всех популярных дистрибутивах линукса X запускается с ключиком -nolisten tcp, а коммуникация между сервером и клиентом происходит через сокеты. более того, в 99.9% случаев это и не нужно. ради 0.01% тащить значительный overhead?
а запускать удаленно программу можно (и нужно) через ssh X forwarding.
DBus практически никаким боком к X и не пристегивается, это совсем другая штука, предназначенная для коммуникации между приложениями.
а запускать удаленно программу можно (и нужно) через ssh X forwarding.
DBus практически никаким боком к X и не пристегивается, это совсем другая штука, предназначенная для коммуникации между приложениями.
я не очень в теме, а ssh x forwarding — это не то же самое, только через ssh?
а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
> а ssh x forwarding — это не то же самое, только через ssh?
нет, X forwarding — это запуск приложеня чрез ssh туннель. а та штука которую мы обсуждаем, нужна для организации удаленной X сессии.
> а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
нет, там хотят сделать отдельный протокол для трея.
см. standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
нет, X forwarding — это запуск приложеня чрез ssh туннель. а та штука которую мы обсуждаем, нужна для организации удаленной X сессии.
> а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
нет, там хотят сделать отдельный протокол для трея.
см. standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
буду знать, спасибо за пояснения
как будто ssh X forwading форвардит UNIX сокеты, а не tcp пакеты
там совсем другой механизм работы, для него совсем не нужна вышеописанная прослойка.
И какой? Такие же сокеты просто проброшенны через ssh.с Сетевая прозрачность нужна, другое дело что не нужна половина классического X11 давно уже не нужна т.к. используются расширения вроде xft и xrender.
со стороны клиента — tcp, со стороны сервера — локальный сокет.
> а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
хотя, возможно, что-то такое в DBus и делают, но это уже не на уровне иксов, а выше, DE/WM.
хотя, возможно, что-то такое в DBus и делают, но это уже не на уровне иксов, а выше, DE/WM.
В технологии X сервером называется клиентский терминал. А клиенты в терминологии X — это приложения, которые запущены на удаленных машинах (множественное число, обратите внимание). То есть ваш терминал (то бишь X-сервер) может отображать окна приложений исполняющихся на разных машинах находящихся в разных концах земного шара.
Что по-вашему в этом случае должен отображать системный трей? Или каждая удаленная машина должна вам в рисовать свой собственный системный трей?
На каждой из этих машин ведь может быть запущен свой dbus. Про сеть dbus ничего не знает, не говоря уже о том, как передать сообщение в ваше приложение в соседнем окне, которое исполняется на другой машине… Надеюсь так понятней должна быть проблема…
Что по-вашему в этом случае должен отображать системный трей? Или каждая удаленная машина должна вам в рисовать свой собственный системный трей?
На каждой из этих машин ведь может быть запущен свой dbus. Про сеть dbus ничего не знает, не говоря уже о том, как передать сообщение в ваше приложение в соседнем окне, которое исполняется на другой машине… Надеюсь так понятней должна быть проблема…
да, забыл добавить. клиент-серверная архитектура разрабатывалась когда в моде были большие мейнфреймы и терминалы.
Так сейчас облака и тонкие клиенты снова становятся модными.
Так что клиент-серверная организация — это тру.
Если все происходит в одной сети организации, то ssh будет лишней тратой ресурсов.
В декстоп-ориентированных дистрибутивах, действительно, имеет смысл по умолчанию отключать сетевое взаимодействие. Однако лет 5 назад, на семинарах по информатике, я очень любил коннектиться с учебного компа на свои домашние иксы и работать на них. Свои настройки, удобно.
Так что клиент-серверная организация — это тру.
Если все происходит в одной сети организации, то ssh будет лишней тратой ресурсов.
В декстоп-ориентированных дистрибутивах, действительно, имеет смысл по умолчанию отключать сетевое взаимодействие. Однако лет 5 назад, на семинарах по информатике, я очень любил коннектиться с учебного компа на свои домашние иксы и работать на них. Свои настройки, удобно.
оно нужно в очень редких случаях. зачем тащить на десктоп клиент-серверную архитектуру иксов если она фактически не используется как задумано но таки вносит свой overhead? а для облаков и прочих тонких клиентов есть более эффективные решения.
Если создавать новые несовместимые протоколы, то будет полный зоопарк графических оболочек. Гном под иксы, гном под DBUS; Кеды под гном и под DBUS и т.д. А потом кто-нибудь придумает еще что-нибудь, и нужно будет создавать новую ветку оконных менеджеров. При этом фичи из одной ветки в другую будут попадать не сразу, и прочие радости от кучи стандартов. Да, а еще разработчикам программ, наверное, тоже надо будет писать кучу лишнего кода для каждой из версий. Плюс в подарок потеря совместимости.
Нафиг-нафиг.
С моей точки зрения вполне логично просто на десктопах отключать сеть, как это происходит сейчас.
К тому же, тут еще вопрос, кто важнее: 1000 юзеров десктопов убунты, или меньшее количество пользователей компании с 1000 компами, которые используют эту фичу в своей работе.
Нафиг-нафиг.
С моей точки зрения вполне логично просто на десктопах отключать сеть, как это происходит сейчас.
К тому же, тут еще вопрос, кто важнее: 1000 юзеров десктопов убунты, или меньшее количество пользователей компании с 1000 компами, которые используют эту фичу в своей работе.
Много там проблем. В какой-то момент отказались от задания шрифтов в X-сервере. Теперь при работе по сети на сервер летят картинки с отрисоваными буковками вместо команды «написано ААА шрифтом БББ». Требования к сети кардинально возросли.
Мне нужна, регулярно иксы по сети использую.
а на самом деле в энтепрайзе vnc и запуск иксовых приложений сквозь сеть распространены повсеместно.
терминал серверы.
ltsp.
eubuntu.
ltsp.
eubuntu.
там и без того с сетью уже не так все хорошо. недавно пробовал krusader запустить и он крашился непонятно почему. старый трюк с export DISPLAY= уже недостаточен.
спасибо за статью)
помнится, запускал я на маке какой-то софт, работающий из-под иксов.
(Х11 в макоси сразу есть)
это такой страх и ужас и нереальный тормоз, что мозгой двинуться можно…
(Х11 в макоси сразу есть)
это такой страх и ужас и нереальный тормоз, что мозгой двинуться можно…
Как всё страшно… Блин, а это даже не Windows с его костылями в WinAPI…
Спасибо. Я и не думал что всё так страшно.
Пробовал писать на XCB оконный Hello World с часиками: это же ужас какой-то! Во-первых, объем кода больше, чем тот же случай на Xlib, раза в два-три. Более того, вменяемой документации по XCB нет. Даже официальный мануал написан очень и очень поверхностно.
Остается качать исходники и заглядывать, анализировать… И после этого обвинять тулкиты в несоответствии стандартам уже как-то не особо и хочется — во имя результата все средства хороши, особенно если они преподносят его на блюдечке. Уж на тот же Qt я по части документации ругаться точно не буду… Не говоря уже о всяких прелестях вроде QtCreator и т.п.
Остается качать исходники и заглядывать, анализировать… И после этого обвинять тулкиты в несоответствии стандартам уже как-то не особо и хочется — во имя результата все средства хороши, особенно если они преподносят его на блюдечке. Уж на тот же Qt я по части документации ругаться точно не буду… Не говоря уже о всяких прелестях вроде QtCreator и т.п.
Согласен, именно внимания к деталям, не хватает многим хорошим проектам. Qt одной только качественной документацией способна прельстить программиста, уставшего от ковыряния разрозненной информации в сети. И пока у XCB не будет более дружественного лица, не появится и мощного сообщества. А жаль…
А в чем проблема насильно портировать Qt и GTK+ на XCB, убрав поддержку Xlib, помимо лени? Ведь подавляющее большинство программ пользуются лишь возможностями тулкитов.
Но что GNOME, что KDE, скорее всего, придется переписывать чуть ли не с нуля.
Но что GNOME, что KDE, скорее всего, придется переписывать чуть ли не с нуля.
Проблема в том, что это лишь мнение одного человека — автора awesome. Вот пришел он, сказал, условно, что Xlib — какашка, а XCB — это очень круто. Придет другой человек, скажет, что Xlib — нормальная, культурно написанная, поддерживаемая и документированная библиотека, а XCB — поделка двух с половиной студентов с неудачным API, плохо документированная и вообще глючащая через раз. И кому верить?
Поставьте себя на место разработчика GTK/Qt. Например, XCB есть сильно не везде. В дистрибутивы оно массово начало вливаться в 2005-2006. Кое-где его до сих пор нет. Сейчас можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения. Менять шило на мыло (о чем, кстати, и говорит автор awesome) с приобретениям какого-то количество явных минусов и небольшого количества эфемерных плюсов, видимо, далеко не все хотят.
Поставьте себя на место разработчика GTK/Qt. Например, XCB есть сильно не везде. В дистрибутивы оно массово начало вливаться в 2005-2006. Кое-где его до сих пор нет. Сейчас можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения. Менять шило на мыло (о чем, кстати, и говорит автор awesome) с приобретениям какого-то количество явных минусов и небольшого количества эфемерных плюсов, видимо, далеко не все хотят.
> можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения
Не заработают :)
Новый Qt/GTK+ требует новый glibc, новый glibc требует новое ядро и далее по списку.
Не заработают :)
Новый Qt/GTK+ требует новый glibc, новый glibc требует новое ядро и далее по списку.
Xlib объективно проигрывает по скорости XCB за счет своей модели запросов. Сверх того, в XCB вся соль в наличии у многих действий, единиц идентификаторов — многопоточный код наворачивать гооораздо безопасней.
Поправьте «Накие-то»
Мне кажется, что слово pager, в баге ООо, в русском переводе должно звучать не совсем пейджер, но, черт возьми, не видно для него другого перевода, как и для еще нескольких слов:(
Я прошёлся по паре ссылок и нашёл определение слова pager в стандарте EWMH:
То есть, это область, в которой рисуются миниатюры окон с рабочих столов (в виде прямоугольников). В XFCE и GNOME эта область назывется "Переключатель рабочих мест". Пожалуй, так и переименую. Надо было проверить это ещё при переводе. My fault :)
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 :)
Страничник :)
а что за пейджер такой?
Можно заметить, что Х — не единственный неидеальный протокол. Все знают семиуровневую модель 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, так что путь эволюции ещё по-видимому не исчерпан. Хотя конечно, революции бывают.
en.wikipedia.org/wiki/Open_Systems_Interconnection — English
ru.wikipedia.org/wiki/Open_Systems_Interconnection — Русский
OSI дал плоды в теории и совсем новых протоколах, но была у них и попытка заменить неидеальный TCP/IP чем-то новым более гибким, а для замены совсем тупого SMTP предлагался монстрик X.400. Иксам по сложности ещё очень далеко до какого-нибудь HTML/CSS, так что путь эволюции ещё по-видимому не исчерпан. Хотя конечно, революции бывают.
Если покопаться, можно найти очень древнее решение, определяющее сегодняшний IT. Ну, все знают по ускоритель шатла и двух римских лошадей.
я не знаю о0"
«Конструкторы многоразового космического корабля „Кеннеди“ не могут увеличить мощность его ускорителей, потому что их диаметр (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. Они описывают статический контент, а от них хотят динамического.
Не распарсил про directFB… Сейчас эта штука в общем то к линуксу гвоздями прибита, там есть серьезные проблемы с I/O драйверами, точнее приходится много плясать, иксы в этом плане хорошую абстракцию дают. Код XInput хорошо бы оставить в любом случае. Вообще по хорошему можно весь рендеринг клиентский на openGL перевести, а его инструкции по отрисовке по сети гонять. Скоро уже все свободные драйвера точно будут уметь openGL аппаратно. Что-то такое как раз в Wayland'е предлагают.
>В итоге опять кучу времени тратим над настройку над Х
Кто тратит? Уже давно всё в тулкитах есть, старые API протокола никто не использует, просто болтается исторически.
>Лучше уже занятся Wayland
Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
>Или уж directFB, там не плохая портированость, а не желания производителей видеокарт под него делать свои драйвера и карты.И есть не адекватная поведение и эффект зеленного экрана.
Так сейчас все опенсорсные драйвера в ядро переезжают, правда я не знаю юзает ли directfb dri. Кстати, разве directfb не linux-only?
>Еще можно рабочее окружение и т.д в полном opengl,openal и opencl отриосвать и сделать, ресурсы позволяют для современных ПК, так извращатся, даже рабоать именно только через них и sdk
Да, EGL/OpenGL/OpenVG было бы круто. Но всё равно помимо EGL ещё нужен слой для управления окнами и воодом.
Кто тратит? Уже давно всё в тулкитах есть, старые API протокола никто не использует, просто болтается исторически.
>Лучше уже занятся Wayland
Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
>Или уж directFB, там не плохая портированость, а не желания производителей видеокарт под него делать свои драйвера и карты.И есть не адекватная поведение и эффект зеленного экрана.
Так сейчас все опенсорсные драйвера в ядро переезжают, правда я не знаю юзает ли directfb dri. Кстати, разве directfb не linux-only?
>Еще можно рабочее окружение и т.д в полном opengl,openal и opencl отриосвать и сделать, ресурсы позволяют для современных ПК, так извращатся, даже рабоать именно только через них и sdk
Да, EGL/OpenGL/OpenVG было бы круто. Но всё равно помимо EGL ещё нужен слой для управления окнами и воодом.
> Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
Если над ним будет работать один Кристиан — то да. Если же люди, которых этот перевод должен был мотивировать заняться X12, вместо этого помог разработке Wayland — всем, я полагаю, будет лучше. Поправьте меня, если я ошибаюсь.
Если над ним будет работать один Кристиан — то да. Если же люди, которых этот перевод должен был мотивировать заняться X12, вместо этого помог разработке Wayland — всем, я полагаю, будет лучше. Поправьте меня, если я ошибаюсь.
Из этой статьи я не уяснил для себя одного — почему же у графического интерфейса X11 такая низкая производительность. Интерфейс Windows XP с его убогим GDI уделывает юникс приложения в пух и прах (и это заметьте без всяких там композит манагеров).
Выходит, что не таким уж и убогим.
при использовании всевозможных расширений типа EXA ни сколечки не уделывает по производительности, но вот разработчики проприетарных драйверов как-то через жопу эти расширения юзают.
Зато виндовый ремоут десктоп это фейл.
Я в подробностях реализации не разбираюсь, но за счёт его синхронности и, видимо, за счёт упомянутой вшитости в ядро он может любой мощности сервер затормозить капитально когда ремоутная сессия по медленному каналу идёт (а если это веб сервер под нагрузкой то канал полюбому занят будет).
Тоесть сервер всегда ждёт пока у клиента всё прорисуеться, и при этом ожидании тормозятся всякие вещи, которые по идее должны были бы быть совершенно независимы. Ясно, что при загруженном канале тормоза начинаются неслабые, и ремоутный сервер начинает нездорово тупить. А ведь через консоль винды и виндогуйные проги особо не поадминистрируешь.
Я как мог описал это в своём блоге (на английском) + пруф видео какое-никакое состряпал — mvmn.wordpress.com/2010/02/11/microsoft-rdp-protocol-a-failure/ — но опять же я в технических деталях не разбираюсь, потому особой информативности не обещаю.
Я в подробностях реализации не разбираюсь, но за счёт его синхронности и, видимо, за счёт упомянутой вшитости в ядро он может любой мощности сервер затормозить капитально когда ремоутная сессия по медленному каналу идёт (а если это веб сервер под нагрузкой то канал полюбому занят будет).
Тоесть сервер всегда ждёт пока у клиента всё прорисуеться, и при этом ожидании тормозятся всякие вещи, которые по идее должны были бы быть совершенно независимы. Ясно, что при загруженном канале тормоза начинаются неслабые, и ремоутный сервер начинает нездорово тупить. А ведь через консоль винды и виндогуйные проги особо не поадминистрируешь.
Я как мог описал это в своём блоге (на английском) + пруф видео какое-никакое состряпал — mvmn.wordpress.com/2010/02/11/microsoft-rdp-protocol-a-failure/ — но опять же я в технических деталях не разбираюсь, потому особой информативности не обещаю.
А для Vista/Win 7 подобная проблема характерна?
ничего что msts едва ли не единственная реализация со вменяемой работой с сессиями, да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы, внц и тому подобный «свободный» шлак.
при желании все няшки винды и ад вполне на ок крутятся из консольных утилит. другое дело что sshd в коробку не положили, это да, печально. а насчет каналов, я уж не знаю какие у вас каналы там, но вот кстате особенно заметна разница между рдп и всем остальным именно на узких каналах. вы бы попробовали в mstsc или в вашем любимом rdesktop'е выкрутить гайки цвета и настройки оформления со стороны сервера в минимум. даже на 256 килобитах с ~1-2 секундной задержкой msts отрабатывает вполне сносно. вот уж чего не скажешь о vnc и прости господи лядского X11.
при желании все няшки винды и ад вполне на ок крутятся из консольных утилит. другое дело что sshd в коробку не положили, это да, печально. а насчет каналов, я уж не знаю какие у вас каналы там, но вот кстате особенно заметна разница между рдп и всем остальным именно на узких каналах. вы бы попробовали в mstsc или в вашем любимом rdesktop'е выкрутить гайки цвета и настройки оформления со стороны сервера в минимум. даже на 256 килобитах с ~1-2 секундной задержкой msts отрабатывает вполне сносно. вот уж чего не скажешь о vnc и прости господи лядского X11.
> ничего что msts едва ли не единственная реализация со вменяемой работой с сессиями,
> да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы
Не знаю так ли это, не имел много возможностей проверить, но по части сесий у RDP уже коммерческая проблема, ибо за сессии приходиться платить, а для не серверных версий так вообще нельзя иметь больше одной сесии — на моих виндах нельзя сидеть за компом одновременно прямо и ремоутно, хотя и версия профешнал а не хоум.
Про тормозные аплинки тоже както не уверен. По крайней мере под Х-ами это не заставит тупить сам сервер, вот и радости. Ну и ясно что главное преимущество линухов и т.п. — возможность более чем адекватного администрированя через терминал. Под виндами же без GUI никуда. Может сами они и ок с консольными утилитами (что тоже не правда), всёравно из сторонних вендоров никто не пишет апликух под винды способных адекватно работать через консоль.
Я даже не знаю можно ли адекватно IIS админить через консоль — подозреваю что нельзя.
Насёт каналов, я уже упоминал что сам канал может быть вполне адекватным, но т.к. сервер то в продакшне и под нагрузкой то скорость сети может быть достаточно низкой.
> да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы
Не знаю так ли это, не имел много возможностей проверить, но по части сесий у RDP уже коммерческая проблема, ибо за сессии приходиться платить, а для не серверных версий так вообще нельзя иметь больше одной сесии — на моих виндах нельзя сидеть за компом одновременно прямо и ремоутно, хотя и версия профешнал а не хоум.
Про тормозные аплинки тоже както не уверен. По крайней мере под Х-ами это не заставит тупить сам сервер, вот и радости. Ну и ясно что главное преимущество линухов и т.п. — возможность более чем адекватного администрированя через терминал. Под виндами же без GUI никуда. Может сами они и ок с консольными утилитами (что тоже не правда), всёравно из сторонних вендоров никто не пишет апликух под винды способных адекватно работать через консоль.
Я даже не знаю можно ли адекватно IIS админить через консоль — подозреваю что нельзя.
Насёт каналов, я уже упоминал что сам канал может быть вполне адекватным, но т.к. сервер то в продакшне и под нагрузкой то скорость сети может быть достаточно низкой.
не надо подозревать, надо открыть и прочитать. IIS можно управлять через его вебморду http(s), так же в IIS 7.0 есть powershell с плагинами для его управления, а еще есть appcmd.exe, — тулза для управления IIS'ом из консоли. вот так-то! альтернатива для msts есть. :)
не представляю каким образом ожидание телодвижений со стороны mstsc заставит «тупить» рабочие задачи. или у вас рабочие задачии в фореграунде в пользовательской сессии? ну тогда msts тут не причем. к слову о рабочих задачах в сессиях, по сей день единственным вариантом тюнинга 1С для работы с большим количеством клиентов по-прежнему является работа через msts (да, еще использования *SQL бакенда, ну да это не суть важно).
у микрасофта в серверных приложениях есть несколько интерфейсов взаимодействия, нынче гуи, павершелл, вебморда и какая консольная тулза. возможно не у всех приложений есть полный набор, но альтернатива есть в любом случае. насчет сторонних программ ничего не скажу, не особо ими пользовался, может быть тут вы правы.
не представляю каким образом ожидание телодвижений со стороны mstsc заставит «тупить» рабочие задачи. или у вас рабочие задачии в фореграунде в пользовательской сессии? ну тогда msts тут не причем. к слову о рабочих задачах в сессиях, по сей день единственным вариантом тюнинга 1С для работы с большим количеством клиентов по-прежнему является работа через msts (да, еще использования *SQL бакенда, ну да это не суть важно).
у микрасофта в серверных приложениях есть несколько интерфейсов взаимодействия, нынче гуи, павершелл, вебморда и какая консольная тулза. возможно не у всех приложений есть полный набор, но альтернатива есть в любом случае. насчет сторонних программ ничего не скажу, не особо ими пользовался, может быть тут вы правы.
не кормите тролля :)
Хорошая статья. А главное, это ведь основа, без которых немыслима работа с UNIX на desktop'е. Надеюсь кто-нибудь найдет в себе силы и перепишет всё как следует.
Дело в том, что X11 это не только сокеты, он также умеет работать и через shared memory, dbus же на сокеты завязан. К примеру в android там тоже весь управляющий трафик по их IPC гоняется (сраный binder), но буферу куда изображения рендерятся лежат в shared memory (кстати у них на это тоже свой велосипед).
Спасибо за перевод! Читал статью в оригинале ещё давно, понял что X11 — самая ужасная и уродливая часть современного Linux-десктопа. Хотел сам написать такую статью, но руки не доходили.
X11 must die.
X11 must die.
В идеале что-то вроде Wayland. Весь рендеринг окна client-side, напрямую в графические буферы, а графический сервер занимается только смешиванием всех буферов в окончательную картинку. Жаль, что Wayland пока не особо шевелится.
Шевелится. Пару месяцев назад Кристиан сменил OpenGL на OpenGL ES. К Qt помаленьку прикручивается поддержка Wayland: cgit.freedesktop.org/~jbarnes/qt-wayland/?h=4.7
Но это не значит, что иксы не должны сдохнуть в муках.
Уродливей разве что OOo :D
Да чтоб тебя. А заменять чем будем, когда умрет?
Die то не надо, а то будем тогда в черных терминалях сидеть, потому-что адекватных замен нет. Другое дело что надо, перерабатывать то что есть. Нужно пересматривать протоколы, переделывать библиотеки и API. Подстраиваться под сегодняшние реалии, добавлять нужное и что важнее избавляться от ненужного, даже если это иногда плохо сказывается на обратную совместимость.
«Кроме того, я думаю, что X11 должен быть разрушен.»
То-то у меня при любом движении мышкой использование CPU подпрыгивает резко… На процесс X уходит… А альтернатив то нету! (
Тем кто реально толкает линуксы в массы (большие корпорации, да?) иксы не нужны, так бы уж давно собрались, договорились и написали.
А так и получается, все, кому всерьез нужен графический интерфейс поверх UNIX-OS (не берем серверные применения) рисуют что-то свое, отличное от X-Window System. Как пример — MacOS X и Android.
никакие большие корпорации линуксы в массы не толкают, а толкают они на рынки серверов, где GUI то и не особо нужен
Есть мнение, что это так и не сдвинется с мертвой точки до тех пор, пока это не будет нужно кому-нибудь типа Google для чего-нибудь типа GoogleOS.
Напомнили про ICCCM. В нём содержится небольшая и игнорируемая «современными» DE (альтернативы которым умрут по мнению автора) заметка. Сервер имеет право отказать в изменении размера окна, и клиент должен рисоваться в той клиентской области, которую ему дадут. Программки вроде XMMS и половины модулей Gnome и KDE это игнорируют, чем создают большие проблемы при использовании фреймовых WM'ов. Сейчас в GSoC вроде появился проект по добавлению фреймового режима в kwin, может и клиенты начнут чинить.
Месье Жульен, видимо, не знает об Икс-Сервере Попова
Качественный и интересный перевод. Спасибо. /*грустно вздыхает*/ Побольше-бы такого контента на хабр.
а как-же QWS как альтернатива? Конечно сейчас это достаточно примитивно — но как минимум KDE на QWS можно запустить, а он в свою очередь может работать и над иксами и над DirectFB и напрямую с видеодрайвером. Очень универсально. Я думаю в таком направлении нужно двигаться.
это чтоже…
«системный трэй» не работает для удалённых клиентов по сети?
неправда, однако.
под кубунтой-9.10 kde-4.3 ltsp-5
на терминалах регулярно (из-за сброса настроек) всплывают уведомления типа
«аудиокарточка %название_аудио_насервере% не работает, переключаюсь на pulsaudio»
тоесть уведомление с сервера отрисовывается на терминале, подключённому по tcp.
что я делаю не так?
«системный трэй» не работает для удалённых клиентов по сети?
неправда, однако.
под кубунтой-9.10 kde-4.3 ltsp-5
на терминалах регулярно (из-за сброса настроек) всплывают уведомления типа
«аудиокарточка %название_аудио_насервере% не работает, переключаюсь на pulsaudio»
тоесть уведомление с сервера отрисовывается на терминале, подключённому по tcp.
что я делаю не так?
Отрисоваться-то он отрисуется — его же иксы рискуют (само сообщение). Вопрос в том, на каких рабочих столах и у каких пользователей :)
ну, с двумя сессиями от одного пользователя даже локально нифига не работает.
а насчёт десктопов вроде всё нормально.
но надо бы проверить.
есть какой-нибудь стандартный способ создать уведомление в kde?
а насчёт десктопов вроде всё нормально.
но надо бы проверить.
есть какой-нибудь стандартный способ создать уведомление в kde?
kdialog --passivepopup отрабатывает на правильном, терминальном десктопе.
другой эксперимент:
флэшка вставляется на сервере и на терминале (пользователи разные),
оповещения о ней появляются вполне корректно.
чисто по опыту, без ртфмства:
либо информация о dbus не верна/устарела,
либо на практике в ltsp используются какие-то хитрости.
флэшка вставляется на сервере и на терминале (пользователи разные),
оповещения о ней появляются вполне корректно.
чисто по опыту, без ртфмства:
либо информация о dbus не верна/устарела,
либо на практике в ltsp используются какие-то хитрости.
И снова попытки делать супер-пупер универсальный велосипед…
Какие-то намёки на OpenGL для удаленных клиентов…
Что за дикость делить систему по библиотекам а не по функционалу?
ЧТо мешает выделить три уровня — аппаратный (отрисовка). Есть не плохой пример — модель DirectX. Сделать тоже самое на OpenGL (собственно уже есть) + аналог DirectInput.
Поверх прикрутить менеджер рабочий столов.
А уже по верх прикрутить удалённый рабочий стол.
Зачем парить мозги попытками передать OpenGL по сети? Это не тот уровень и не та задача. Гнать нужно уже уровень окон.
И будет замечательная структурированная быстрая и логичная система.
А проблема, кстати, характерна для большинства Linux — софта. Софт разрастает, никто не хочет править старое и никто не хочет документировать — все хотят писать новое. Расширения плодятся. И стоит заикнуться о том что код превратился в болото, что нет не то что документации, а даже способа её получить, так как разработчики ушли, и никто кроме них в недокументированных фичах и настройках не разбирался, что структура проекта утеряна на прочь и он полон взаимопротиворечиых расширений, как поднимается вонь до небес! Начинаются вопли о совместимости столетного оборудованния и софта (и что, из за того, что кто-то где-то использует старьё, весь остальной мир должен довольствоваться тормозами и глюками.
Начинаются истерики по поводу портирования 1% расширений, которые использует 1% пользователей. И им насрать, что есть более новые и логичные расширения — не переписывать же им свой 1% кода?! Нет. Пусть все остальные тянут с собой это болото.
А уж какие крики о неподъёмной трудоёмкости… Видите ли нужно обязательно тянуть с собой всё болото и тестировать ена вековом оборудовании.
А большая же часть аргументов сводится к тому, что «работает, ну и ладно — на наш век хватит, а там разберутся».
Одно ядро достаточно взять… Вместо того, чтобы разработать/переработать/документировать стандарт на модули драйверов видеокарт все с крим ура лезут голой жопой на кактус и ратуют за их включение непосредственно ядро. Получается чёрный ящик в чёрном ящике. И никто не думает о том, кто и какими силами потом будет тянуть всё это болото по мере увеличения разнообразия видеокарт.
Короче, говоря — иногда демократия это плохо. И для мира *nix наступает именно такой момент. Корпорации и производители закрытого софта могут волевым решением сменить архитектуру, выкинуть лишнее, изменить идеологию, заставить пользователей обновить железо. Да, каждый раз вопли, слёзы и сопли, но тем не менее это избавляет от мёртвого кода и не нужно совместимости.
В общем, я лично категорически не понимаю, какой будет выход у сообщества открытого софта.
Какие-то намёки на OpenGL для удаленных клиентов…
Что за дикость делить систему по библиотекам а не по функционалу?
ЧТо мешает выделить три уровня — аппаратный (отрисовка). Есть не плохой пример — модель DirectX. Сделать тоже самое на OpenGL (собственно уже есть) + аналог DirectInput.
Поверх прикрутить менеджер рабочий столов.
А уже по верх прикрутить удалённый рабочий стол.
Зачем парить мозги попытками передать OpenGL по сети? Это не тот уровень и не та задача. Гнать нужно уже уровень окон.
И будет замечательная структурированная быстрая и логичная система.
А проблема, кстати, характерна для большинства Linux — софта. Софт разрастает, никто не хочет править старое и никто не хочет документировать — все хотят писать новое. Расширения плодятся. И стоит заикнуться о том что код превратился в болото, что нет не то что документации, а даже способа её получить, так как разработчики ушли, и никто кроме них в недокументированных фичах и настройках не разбирался, что структура проекта утеряна на прочь и он полон взаимопротиворечиых расширений, как поднимается вонь до небес! Начинаются вопли о совместимости столетного оборудованния и софта (и что, из за того, что кто-то где-то использует старьё, весь остальной мир должен довольствоваться тормозами и глюками.
Начинаются истерики по поводу портирования 1% расширений, которые использует 1% пользователей. И им насрать, что есть более новые и логичные расширения — не переписывать же им свой 1% кода?! Нет. Пусть все остальные тянут с собой это болото.
А уж какие крики о неподъёмной трудоёмкости… Видите ли нужно обязательно тянуть с собой всё болото и тестировать ена вековом оборудовании.
А большая же часть аргументов сводится к тому, что «работает, ну и ладно — на наш век хватит, а там разберутся».
Одно ядро достаточно взять… Вместо того, чтобы разработать/переработать/документировать стандарт на модули драйверов видеокарт все с крим ура лезут голой жопой на кактус и ратуют за их включение непосредственно ядро. Получается чёрный ящик в чёрном ящике. И никто не думает о том, кто и какими силами потом будет тянуть всё это болото по мере увеличения разнообразия видеокарт.
Короче, говоря — иногда демократия это плохо. И для мира *nix наступает именно такой момент. Корпорации и производители закрытого софта могут волевым решением сменить архитектуру, выкинуть лишнее, изменить идеологию, заставить пользователей обновить железо. Да, каждый раз вопли, слёзы и сопли, но тем не менее это избавляет от мёртвого кода и не нужно совместимости.
В общем, я лично категорически не понимаю, какой будет выход у сообщества открытого софта.
фразой «гнать уровень окон» вы имеете ввиду передавать по сети уже отрендерёные картинки целых окон?
3D ваще очень капризная и требовательная штука и для хорошей работы количество слоев больше чем ядро-дрова-OpenGL неприемлемо впринципе. Попытки наложить сложную графику на клиент-сервеную архитектуру — так вообще срамота на костылях. И вместо того, чтобы переработать и все оптимизировать по человечески, все придумыывают новые костыли пверх сущестующих, а поверх этих еще одни, и еще и еще.
Я считаю что графическую систему(иксы в данном случае) надо делать одним цельным куском без разбиения на клиента и сервера.
Я считаю что графическую систему(иксы в данном случае) надо делать одним цельным куском без разбиения на клиента и сервера.
Спасибо автору.
Ситуация из последнего абзаца показательна не только для X-ов, но и для большинства продуктов с долгой историей.
Ситуация из последнего абзаца показательна не только для X-ов, но и для большинства продуктов с долгой историей.
Благодарю за труд, статья из разряда очень интересных.
Дык это, давайте популяризировать проблему, писать на ЛОРах о ней, на Опеннетах, в уютненьких жж-шечках, итд. И все это с лозунгами мол набираем девелоперов. И потом к получившемуся шуму можно за нос притянуть тех же девелоперов X11 и KDE и Gnome. Ну, это в теории.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мысли вслух о протоколе X