В Wayland добавлена поддержка multi-touch

Держи вот в догонку, чтобы лучше думалось.

$ x11trace -n lxappearance 2>/dev/null | grep Request | cut -d: -f6 | cut -d' ' -f2 | sort | uniq -c | sort -n
      1 ConfigureWindow
      1 CreateCounter
      1 DestroyCounter
      1 Enable
      1 FillPoly
      1 GetCrtcInfo
      1 GetMap
      1 GetNames
      1 GetOutputPrimary
      1 GetScreenResourcesCurrent
      1 Initialize
      1 ListInputDevices
      1 OpenFont
      1 PerClientFlags
      1 QueryBestSize
      1 QueryPictFormats
      1 QueryTree
      1 SelectInput
      1 SendEvent
      1 UnmapWindow
      1 UseExtension
      2 Attach
      2 CreateGlyphSet
      2 DeleteProperty
      2 DestroyWindow
      2 GetExtensionVersion
      2 GetGeometry
      2 GetWindowAttributes
      2 OpenDevice
      2 SelectEvents
      2 SelectSelectionInput
      3 GetOutputInfo
      3 GetSelectionOwner
      4 MapWindow
      6 CreateWindow
      6 SetInputFocus
      7 GrabServer
      7 UngrabServer
      8 GetProperty
      8 QueryVersion
      9 CreateGlyphCursor
     10 PolySegment
     11 GetInputFocus
     15 QueryExtension
     19 QueryPointer
     25 CopyArea
     26 FreeGC
     32 CreateGC
     36 ChangeWindowAttributes
     39 PutImage
     41 Composite
     52 InternAtom
     58 TranslateCoordinates
     59 ChangeProperty
     68 FreePixmap
     72 ChangePicture
     77 CreatePixmap
     85 CompositeGlyphs8
    116 PolyFillRectangle
    119 Trapezoids
    121 CompositeGlyphs16
    124 FreePicture
    129 AddGlyphs
    140 CreatePicture
    149 SetClipRectangles
    199 SetPictureClipRectangles
    372 ChangeGC
    496 FillRectangles

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

Причем тут декодирование средствами видеокарты. Картинка из плеера гонится прямым потоком битмапов. Если конечно там нет специального забубенного костыля для этого.

Но проблема современных тулкитов в том, что они рисуют все у себя в памяти, а на экран выводят готовую картинку.

4.2.

Как раз надо тебе подучить матчасть. В Qt все рисование offscreen и это написано в документации черным по белому. И обрати внимание как прорисовываются кутэшные приложения, когда им не хватает ширины канала.

В Qt все рисование offscreen и это написано в документации черным по белому.

Если для тебя offscreen == на стороне клиента, то у меня для тебя плохие новости: тебе надо идти учить матчасть. Впрочем, меня в любом случае мало волнует, как там рисует этот тулкит-переросток. GTK рисует правильно.

1. не знаю, что думает по этому поводу ктулху, но мне вообще пофиг. У меня основная задача - анально отгородить иксы от удаленных машин. В случае с локальными юзерами - мне не проблема написать баш скрипт из двух строчек, который будет через sudo запускать от разных юзеров разные приложения, при этом импортируя нужные печеньки перед запуском. Т.е. можно тупо запускать B от юзера B с правами ограниченными, а A от юзера A с правами неограниченными. Есть только вопрос касательно dbus'а - если запустить компиз от другого юзера (неограниченного), то он будет нормально работать с приложениями основного (ограниченного) юзера?
2. А разве gtksudo изначально от рута не работает? вроде, оно и должно работать от рута через suid-бит.

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

возможно, Вы не так выразились, но поясню, что приложение ничего не должно контролировать, просто иксы не должны давать доступ к функциям граббинга, перехвата и посылки, если они не запущены со специальными печеньками.
если касалось темы подмены приложения на похожее - если совсем паранойя мучает, то можно заходить под рутом с другого компа или переключаться в VT. не вижу реальной необходимости в этом.
3. вообще не понял к чем это? причём тут мандатный доступ? Нам просто надо разграничить приложения на A и B. А (основная часть приложений) не могут иметь доступа к функциям граббинга, перехвата и посылки (либо убить приложение/завершить его X11-сеанс с сервером, либо сделать вид, что всё работает, но никаких данных не отдавать). Что касается файлов ключей - ктулху же сказал, что самый хороший вариант - это через магические печеньки организовать. они хранятся в файле .Xauthority и к нему и так и так имеет доступ только его владелец (ну и рут, но на него класть, т.к. если на моей машине кто-то получит рута, то у меня будут проблемы посерьезнее, чем скриншотинг иксов).

ответственно, смысл в том, чтобы заставить Xorg подхватить файл .Xauthority ( http://www.intuit.ru/department/security/issec/3/2.html ), а не самому генерировать его. в нём мы укажем кучу разных печенек. Части (или вообще только одной, можно даже в код вшить) из них мы дадим привилегированный доступ, остальным - обычный.

(1280*1024*4*25) / 1048576 = 125 МБайт/сек

а я и не говорил, что смотрю во весь экран. Гигабита, получается, должно хватить.

Если для тебя offscreen == на стороне клиента, то у меня для тебя плохие новости: тебе надо идти учить матчасть.

Твоя правда, сейчас потестил. Действительно, есть два бэкенда - raster и x11, первый рисует в памяти приложения и ощутимо тормозит по сети, второй пользует иксовые пиксмапы.

Замолкаю )

Жаль x11trace у меня в репах нету (

который будет через sudo запускать от разных юзеров разные приложения

Проблема в том, что это не получится 1 раз прописать политики и, скажем, засунуть их в дистрибутив. Придётся везде зависеть от sudo и его правильных настроек, и обвешиваться кучей вспомогательных скриптов.

возможно, Вы не так выразились, но поясню, что приложение ничего не должно контролировать, просто иксы не должны давать доступ к функциям граббинга, перехвата и посылки, если они не запущены со специальными печеньками.

Печеньки печеньками, а у приложения должна быть возможность явным образом дропнуть любые ACL, назначенные на его окно. Потому что у разработчика gtksu нет никаких оснований доверять вашей скриншотилке, даже если лично вы её доверяете.

А разве gtksudo изначально от рута не работает? вроде, оно и должно работать от рута через suid-бит.

Работает. Именно поэтому визуальная аутентификация и возможна. :)

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

Я зато вижу. Вы можете представить обычного усредненного пользователя линукс, который переключается в чистую консоль каждый раз, когда надо ввести пароль? Я — не могу. А вот вариант визуальной аутентификации окна гораздо более жизнеспособен. В конечном счете, когда доля десктопных/мобильных систем с линуксом на борту превысит определенный порог, трояны полезут неизбежно. Равно как и общий уровень компьютерной грамотности пользователей снизится.

Нам просто надо разграничить приложения на A и B.

Задача — разграничить их, не меняя euid. Из тех же соображений о «среднем пользователе». Эту задачу позволяет решить SELinux / AppArmor.

Части (или вообще только одной, можно даже в код вшить) из них мы дадим привилегированный доступ, остальным - обычный.

Костыльно. Почему бы сразу не сделать полноценные ACL на фичи протокола и гибкие конфиги к ним? Что я и планирую. Это позволит конфигурировать систему под любые варианты использования.

Проблема в том, что это не получится 1 раз прописать политики и, скажем, засунуть их в дистрибутив. Придётся везде зависеть от sudo и его правильных настроек, и обвешиваться кучей вспомогательных скриптов.

compiz/kwin, скриншотмейкер, xdotool можно запускать из под отдельного юзера. для трёх с половиной приложений проблем в таком скрипте не вижу. для основного юзера и удаленных - обычные настройки (запрещено), в чём проблема?

Печеньки печеньками, а у приложения должна быть возможность явным образом дропнуть любые ACL, назначенные на его окно. Потому что у разработчика gtksu нет никаких оснований доверять вашей скриншотилке, даже если лично вы её доверяете.

не думаю, что это хорошая идея. т.к. почти все начнут этим заниматься, а я считаю себя умнее системы :)

Костыльно. Почему бы сразу не сделать полноценные ACL на фичи протокола и гибкие конфиги к ним? Что я и планирую. Это позволит конфигурировать систему под любые варианты использования.

каким образом Вы себе это представляете? Вы хотите переписать X11 под эту задачу? это весьма глупо, ИМХО. тем более, сомнительно, что подобная технология когда-нибудь войдёт в мейнлайн, и уж тем более будет доступна для обычно юзера. а перекомпилировать X11lib - не айс. К тому же на удаленных клиентах это не прокатит (не желательно). Или как Вы планируете без переделывания клиентской части реализовать пересылку аутиентификационных данных? помоему, лучше взять уже имеющиеся cookie за них. Если нужно из-под одного юзера запускать, то можно через SELinux запретить доступ к .key, куда будут cookie для привилегированных процессов класться, но реализовать это без перекомпиляции приложений всё-равно не получится. И, тем более, использование SELinux / AppArmor является куда большей проблемой, чем запуск 1-3 приложений из-под отдельного юзера.

А тачпад там уже работает в относительном режиме, а не как тачскрин?

А вот вариант визуальной аутентификации окна гораздо более жизнеспособен.

пффф... и как Вы предлагаете защититься? я просто возьму и сделаю (скомпилю, немного подправив) gksudo, который будет запускаться из-под обычного юзера, после ввода пароля отправлять его куда надо и вызывать sudo/su с ним. И никакое разграничение доступа не поможет. В данном случае единственный вариант - переделать gksudo так, чтобы он выдавал секретный PIN-код из файла в своём окне. На чтение этого файла только у рета будут права. И вот в этом случае разграничение доступ поможет, т.к. из привилегированных у нас только kwin/compiz/shutter, которые точно проверенны, а остальные никак не смогут спалить экран и, следовательно, PIN. видим PIN - точно знает, что gksudo тот.

там ничего не работает. просто они пиарятся.

там ничего не работает

Да, я запускал это через KMS-фреймбуфер. Ни одна демка, кроме самого compositor, не запустилась (а может, я не осилил? но инструкций по запуску никаких нет). И при этом фигово работал тачпад. Вроде, оно же использует evdev, а через него тачпад тоже фигово работает, но хоть в относительном режиме (с gpm, например).

не думаю, что это хорошая идея. т.к. почти все начнут этим заниматься, а я считаю себя умнее системы :)

Тогда вводим выделенный идентификатор root, которому можно всё. Собственно, всё давно изобретено до нас.

каким образом Вы себе это представляете?

Как расширение протокола.

Вы хотите переписать X11 под эту задачу? это весьма глупо, ИМХО.

ИМХО — это неубедительная аргументация. При обработке конкретных запросов и событий в любом случае придётся решать: можно или нельзя. А уж как именно мы будем это делать — это инкапсулированный кусок функциональности, который не оказывает влияния на сложность патчинга остальных компонент.

а перекомпилировать X11lib - не айс. К тому же на удаленных клиентах это не прокатит (не желательно).

Клиент, не работающий с новыми возможностями, просто получает дефолтные параметры, настроенные в иксах для его печеньки. Клиент, имеющий пересобранную xlib и знающий о новых фичах, может выполнять что-то полезное для себя: дропать дефолтные права со своих окон, аутентифицироваться с новыми идетификаторами или дропать свою аутентификацию. Снова не вижу проблемы.

Или как Вы планируете без переделывания клиентской части реализовать пересылку аутиентификационных данных? помоему, лучше взять уже имеющиеся cookie за них.

По ним и будем работать. Дополнительные фишки потребуются лишь когда клиент хочет управлять своими параметрами безопасности.

Если нужно из-под одного юзера запускать, то можно через SELinux запретить доступ к .key, куда будут cookie для привилегированных процессов класться, но реализовать это без перекомпиляции приложений всё-равно не получится.

Не вижу, откуда такой вывод следует.

И, тем более, использование SELinux / AppArmor является куда большей проблемой, чем запуск 1-3 приложений из-под отдельного юзера.

AppArmor использует маски типа @{HOME}/somepath/*. Так что это довольно удобно. Вообще я просто рассматриваю предлагаемую архитектуру с точки зрения «а чего захочет с ней сделать админ / дистростроитель?». Захочет sudo использовать? Отлично, не вижу препятствий для этого. Захочет рулить правами в пределах одного uid? Ок, можно MAC для этого задействовать.

Однако архитектура состоит из нескольких слоёв:

• Базовые патчи на иксы, позволяющие ответить на вопрос можно/нельзя, но не реализующие конкретного механизма проверки.
• Механизм привязывания прав к печенькам и конфиги к нему.
• Расширение протокола для управление правами со стороны клиента.

Т.к. вас последний пункт не интересует, в ТЗ можно ограничиться первыми 2-мя.

пффф... и как Вы предлагаете защититься?

В данном случае единственный вариант - переделать gksudo так, чтобы он выдавал секретный PIN-код из файла в своём окне. На чтение этого файла только у рета будут права. И вот в этом случае разграничение доступ поможет, т.к. из привилегированных у нас только kwin/compiz/shutter, которые точно проверенны, а остальные никак не смогут спалить экран и, следовательно, PIN. видим PIN - точно знает, что gksudo тот.

Вы сами описали именно то, о чем я и говорил парой сообщений выше.

Вообще там много всего веселого.

Например, если мы хотим быть уверены, что клиент C не подслушает ввод окна W, надо:

• Запретить клиенту C слушать события ввода из очереди этого окна.
• Запретить клиенту C слушать состояние клавиатуры, когда окно W имеет фокус.
• Запретить клиенту C эксклюзивный захват устройств ввода, когда окно W имеет фокус.
• Запретить клиенту C переключать фокус, когда окно W имеет фокус.

пока не будет плагина для сетевой прозрачности и полноценного слоя совместимости с X11(для «устаревших» приложений) лично мне эта срань нафиг не упала

не пользуйся говном, пользуйся нормальными драйверами, очевидно же :-)

два Х сервера не могут быть одновременно активными на одной машине, даже если будешь иметь для каждого сервера свой набор из графической карты, мышки и клавиатуры.

охлол. Ну тогда я из атсрала такую конфигурацию настраивал.

P.S. Видяхи обе - внешние, PCI-Express. С встроенной и внешней такое как правило не прокатит, но тут проблема скорее всего не в иксах...

ждем много чего

вот когда это «много что» в вяленде будет(про слой совместимости я уже упоминал) - тогда и посмотрим. А пока - не нужно!

ты хотел сказать в поставку Ubuntu :-)

Wine не создаёт полноэкранный режим. Он создаёт окно без рамочки.

зависит от настроек

алгоритмом сжатия быстрее, плюс на чистом Xlib приложения щаз уже не пишут, а тот же Qt из-за своего window polling может засрать сеть по самое не балуй. ssh-forwarding с принудительно включенным сжатием конечно помогает, но не сильно - это факт. Тем не менее, ИМХО это не повод отказываться от сетевой прозрачности совсем

это достигается увеличением приоритета оконной системы

GUI в винде неотделим от ядра, поэтому и работает быстрее. Как в макоси - хз.

а тот же Qt из-за своего window polling может засрать сеть по самое не балуй

Что за опрос окон?

P.S. Видяхи обе - внешние, PCI-Express. С встроенной и внешней такое как правило не прокатит, но тут проблема скорее всего не в иксах...

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

на нормальных ноутах и компах - без проблем.

все компы, что я встречал при вставке PCI Express видео отключали нахрен встроенную. То есть, даже в lspci она не видна...

Однако архитектура состоит из нескольких слоёв:

1.Базовые патчи на иксы, позволяющие ответить на вопрос можно/нельзя, но не реализующие конкретного механизма проверки.
2.Механизм привязывания прав к печенькам и конфиги к нему.
3.Расширение протокола для управление правами со стороны клиента.

ага, нужны только 2 первых. т.к. я в душе не представляю, что, кроме sudo-gui будет явно запрещать вообще для всех (да привилегированных) запрещать доступ. в конкетном случае не вижу никаких причин городить огород с дополнением протокола для этих приложений.
мало того, тут следует понимать, что для sudo-gui приложений запрет на скриншотинг не обязателен, тут важно только перехват запретить.

далее есть следующие проблемы:
1. надо не отказывать непривилегированным в действии, а посылать пустой ответ(в случае клавиш)/белый(или черный) фон. т.к. иначе возможен вылет приложения.
2. если я не ошибаюсь, Xorg не умеет больше одной печеньки генерировать для себя, а тут надо. мало того, весьма желательно подгружать/выгружать (хотя бы для непривилегированных) новые печеньки на лету или включать/выключать существующие. т.к. после сеанса с удаленным сервером стоит отозвать печеньки.
3. если возможно обойтись без модификаций протокола, т.к. (особенно в kwin и compiz) патчинг может быть проблематичным, а в данном случае и не нужным.
4. как будет работать d-bus в случае, если compiz/kwin будет запущен от другого юзера?
5. я рассматриваю задачу с точки зрения её простейшей реализации и простейшего использования. я нисколько не спорю, что можно дополнить протокол потрахаться с apparmor/selinux и что это, в принципе, правильно, только другой вопрос, что я - не каноникал, чтобы потом её заниматься постоянным решением вопросов с последующими глюками пересобранных приложений. и если Вы реально считаете, что это будет использовать кто-то, кроме юзеров hardened gentoo и ещё полутора параноидальных анонов, то Вы ошибаетесь (давайте всё-таки смотреть правде в глаза). и ни в какие дистрибы это точно не включат (скорее всё от вяленное творение сделают).

ну и самый интересный вопрос (который уже задавал ктулху): сколько это будет стоить?

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

Вы тоже несколько не понимаете, что реализация видеоподсистемы в ядре с прямым доступом к дровам из юзерспейса - прямой путь к протрояниванию ведра и панике ведра при сбое вайланда.

Да, здесь я подробностей не знаю, правда ли прямой доступ к дровам из юзерспейса. Но к ненужности сетевой прозрачности как это относится слабо понимаю.

ненужности сетевой прозрачности

весьма нужной

То есть если впилить wayland в ядро, он тоже будет быстрее иксов?

Нужна нормальная сетевая прозрачность для всех приложений, а не только написанных на чистом xlib. Или вообще другая не нужна - vnc можно поднимать поверх любой системы, x11 уже работает и для задач с терминалами и удаленной администрацией может использоваться еще бесконечно долго, независимо от успеха wayland или чего-то другого.

1. надо не отказывать непривилегированным в действии, а посылать пустой ответ(в случае клавиш)/белый(или черный) фон. т.к. иначе возможен вылет приложения.

Да, само собой.

2. если я не ошибаюсь, Xorg не умеет больше одной печеньки генерировать для себя, а тут надо. мало того, весьма желательно подгружать/выгружать (хотя бы для непривилегированных) новые печеньки на лету или включать/выключать существующие. т.к. после сеанса с удаленным сервером стоит отозвать печеньки.

1. Аутентификация.

Иксы могут авторизовать/аутентифицировать клиента следующим образом: при помощи MAGIC-COOKIE, при помощи DES-ключа (XDM-AUTHORIZATION) или при помощи авторизации у доверенного лица через Secure RPC. Про последний способ я ничего кроме общих сведений не знаю, так что оставим его пока за бортом.

Что касается MIT-MAGIC-COOKIE-1 и XDM-AUTHORIZATION-1, тут всё просто как 3 копейки — «если твой ключ есть в Xauthority сервера, ты имеешь доступ». Разница только в том, что в первом варианте ключи пересылаются в открытом виде. Сервер генерацией ключей заниматься не обязан, и он этим и не занимается.

При этом по своей сути база ключей не является механизмом аутентификации, а только авторизации. Прежде чем продвинуться дальше, нам нужно реализовать механизм идентификации и аутентификации клиента. Т.е. у нас будет цепочка клиент -> ключ -> идентификатор.

Ключ одновременно является и средством идентификации и средством аутентификации. В этом слабость такой схемы, и по идее, ключи должны быть временными сеансовыми «печеньками». Однако это выходит за рамки иксов, это могут делать внешние утилиты.

Итак, у нас есть таблица ключ->идентификатор. Клиент, прошедший авторизацию доступа к серверу, одновременно при помощи этого же ключа идентифицируется и аутентифицируется под соответствующим идентификатором.

(А в случае использования Secure RPC мы можем надежно аутентифицировать клиента как username@hostname, вот тут-то оно бы нам и пригодилось вместо возни с ключами, кстати.)

Как бы то ни было, в итоге мы назначаем клиентскому подключению идентификатор. Обзовём этот идентификатор X User Id == xuid, потому что надо его же как-то называть.

2. Группы.

Далее нам нужна таблица идентификатор -> список групп. Идентификаторы групп (xgid) участвуют в проверках прав доступа наравне с xuid, собственно, точно так же, как в юниксе gid-ы и используются.

3. ACLs.

После того, как подключения у нас перестали быть безымянными, следующая задача: решить, какие ACL будут иметь создаваемые клиентом окна. ACL представляет собой список элементов вида [идентификатор, набор разрешений].

Решение тут — назначать права окну по шаблонам. Каждый шаблон — это правило вида «если владелец окна принадлежит к группе G, то в ACL его окон добавляются элементы X, Y, Z.»

Например, пусть нам необходимо следующее поведение «xneur может читать/писать ввод окон клиентов группы local». Шаблон записываем в обратную сторону: «Если клиент принадлежит к группе local, xneur может читать/писать его ввод». На формальном языке это может выглядеть примерно так:

local {	xneur allow watch input, allow send input;}

Права доступа я рассматривать пока не буду, вернёмся к авторизации. Итак, иксам необходимо уметь:

• идентифицировать и аутентифицировать подключение
• получить по идентификатору ассоциированный с ним список групп
• получить шаблоны ACL для групп

В идеале — всё это должно иметь модульную структуру, позволяющую использовать любой backend. В простейшем случае, который рассмотрен выше, для аутентификации используются те же ключи, что и для авторизации доступа, а группы и шаблоны лежат в плоских файлах. В перспективе, это всё может лежать где-нибудь в OpenLDAP (поддержку чего я, слава богу, реализовывать не собираюсь, но кто-нибудь однажды захочет это сделать...).

На практике, при использовании иксов на локальной машине с локальными клиентами ключи можно использовать статические (не меняющиеся между перезапусками сервера), либо же перегенерировать их скриптом при логине из DM. Авторизация доступа к файлам ключей может использоваться на основе прав доступа файлов или на основе MAC.

При использовании удаленных клиентов, дела обстоят сложнее. Конечно, мы можем хранить статические ключи на удаленной машине. Но из соображений безопасности так делать не стоит. В случае использования ssh я вижу этот процесс следующим образом:

• Пользователь, желающий запустить приложение на удаленной машине, в параметрах ssh указывает xuid, который будут использовать удаленные клиенты.
• ssh выполняет аутентификацию данного xuid-а. (Убеждается, что данный uid может выступать от имени данного xuid-а.)
• ssh создаёт новый ключ для данного xuid-а, записывает его в карту ключ->xuid и добавляет ключ в Xauthority
• Далее ssh как обычно выполняет подключение к удаленной машине, аутентификацию пользователя и создаёт проксисервер иксов.
• Когда удаленные приложения подключаются к проксисерверу на удаленой машине, ssh используя сгенерированный ключ обеспечивает их подключение к локальному икс-серверу. Сервер аутентифицирует подключение как имеющее соответствующий xuid.
• При закрытии ssh, она удаляет соответствие ключ->xuid в карте соответствий и удаляет ключ из Xauthority.

3. если возможно обойтись без модификаций протокола, т.к. (особенно в kwin и compiz) патчинг может быть проблематичным, а в данном случае и не нужным.

Я пока не вижу никаких причин менять протокол. Расширение — возможно, как необязательная опция. Изменение — нет.

4. как будет работать d-bus в случае, если compiz/kwin будет запущен от другого юзера?

Dbus подключается через abstract socket. Будь это обычный unix socket, можно было бы выставить права на файл. В случае abstract socket я не знаю, какие есть у него права, как они настраиваются, и есть ли они у него вообще. Файла-то у такого сокета нет. Но я думаю, dbus имеет поддержку unix socket, так что настроить всё это — не проблема. Надо будет изучить этот вопрос.

5. я рассматриваю задачу с точки зрения её простейшей реализации и простейшего использования. я нисколько не спорю, что можно дополнить протокол потрахаться с apparmor/selinux и что это, в принципе, правильно, только другой вопрос, что я - не каноникал, чтобы потом её заниматься постоянным решением вопросов с последующими глюками пересобранных приложений. и если Вы реально считаете, что это будет использовать кто-то, кроме юзеров hardened gentoo и ещё полутора параноидальных анонов, то Вы ошибаетесь (давайте всё-таки смотреть правде в глаза). и ни в какие дистрибы это точно не включат (скорее всё от вяленное творение сделают).

Вы слишком мрачно смотрите на вещи. MAC полезна в ентерпрайзе. MAC будет полезна на десктопе, как только у криминального элемента появится мотивация делать под линукс трояны. При этом вопрос «глюков пересобранных приложений» — это вопрос исключительно размера юзербазы. Если есть что отлаживать, желающие ловить баги найдутся, как только припрёт необходимость. А вот если и отлаживать нечего, это печальнее.

ну и самый интересный вопрос (который уже задавал ктулху): сколько это будет стоить?

А вот это самый сложный вопрос. Надо подумать.

протокол X1 предназначен для использования внутри локалки (видео смотреть можно вполне). если Вы чешете ухо ногой, то это никак не проблемы разработчиков.

Гибкость и прозрачность (:

хз, у меня недостаточно знаний чтобы это утверждать. Но то, что будут возможны такие эпичные баги, как баг в GDI+ у мелкомягких с повышением привилегий до уровня системы - это к гадалке не ходи

Нужна нормальная сетевая прозрачность для всех приложений

плюсую

Поддерживаю вендора. Составляйте техническое задание, высталяйте счёт. Задача у меня та же, что и у вендора. В данном случае самое важное чтобы:
1. Запрет перехвата нажатий кнопок клавиатуры всем, кроме xneur и compiz.

Уже смешно. Вы в исходники xneur смотрели? Там готовый логгер, да ещё с возможностью отправки лога по почте. Остаётся только незаметно адресок подсунуть.

Все банально

Допустим. Как «тормознусть» оценивать будем? По ощущениям?

Серия проведенных экпериментов не выявила каких-либо заметных различий в «тормознутости» работы графической системы винды (XP Home) и линукса (kde4@Debian Squeeze). По ощущениям.

Вывод: либо Ваше утверждение не верно, либо предлложенная Вами методика не актуальна, либо погрешность измерений не позволяет выявить различий.

Лучше бы они еще какой-нибудь плеер/браузер делали.

*facepalm*

Тебе плееров в линуксах не хватает?

man сарказм :)

От очередного браузера/плеера линуксу ни горячо, ни холодно. А вот выпиливание иксов очень серьезно на все повлияет.

man сарказм :)

Я облажался :)

Подумал, что ты из тех, кто вопит о бесполезности сабжа.

извиняюсь, что так долго не отвечал, просто у меня были некоторые личные дела: http://s.lurkmore.to/images/4/49/Awesome_booty.png

в общем под иксы уже есть реализация XACE (X Access Control Extension), обеспечивающая безопасность:
http://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.html
https://www.mediawiki.org/wiki/Extension:Improved_Access_Control
https://www.nsa.gov/research/_files/selinux/papers/xorg07-paper/node4.shtml
http://www.opennet.ru/base/sec/selinux_tips.txt.html
http://www.x.org/releases/X11R7.6-RC1/doc/xorg-docs/specs/Xserver/XACE-Spec.ps (открыть в evince или другой совместимой программе)

судя по всему, почти всё, как Вы и задумывали, даже больше.

мало того, вот тут написано всё с картинками и, якобы, в userspace интерфейсом от SELinux, но я не совсем понял, то ли это, что надо:
http://selinuxproject.org/page/NB_XWIN

кстати, до XACE был XSecurity ( http://www.xfree.org/current/security.pdf ), однако, был заменен на XACE.

также наткнулся на XACML ( http://www.w3.org/2009/policy-ws/papers/Neven.pdf ). Но тут вообще не понятно, теоретическая ли задумка или был, хотя бы, пруф-оф-концепт.

насколько я понял, после определенной версии иксов его выпилили.

1. возможно ли запилить обратно?
2. и, соответственно, какова стоимость для данной работы (проще же получается. или я не прав?)?
3. я правильно понял, что SELinux Project уже сделал к нему (XACE) UI, или, как написано в его спеках (или я неправильно их понял?), его надо сделать самому?
4. правильно ли я понял, что оно позволит делать всё, о чём мы разговаривали?

при учёте kwin+DRI+opengl backend для GTK/Qt (который полюбому нужен для wayland, но может также и под исксами работать) - никакого смысла в нём нет. Если считаете иначе, объясните чем он лучше, учитывая, что:
1. opengl backend для GTK/Qt в любом случае надо писать под вайланд, хотя и под Xorg+DRI будет работать ТАКЖЕ (по скорости).
2. располагается внутри ядра - менее стабильный
3. располагается внутри ядра - менее безопасный
4. Xorg уже работает
5. Xorg легко перезапустить, чего не скажешь о модуле ядра
6. я могу легко запустить столько Xorg'ов, сколько хочу. причём как на одном дисплее, так и на нескольких. так и на нескольких видяхах
6.1 как мне сделать сервер терминалов на вайланде?
7. легко можно организовать мультисит
8. мультитач, а также ещё куча устройств, начиная от тачпадов и планшетами и заканчивая вагинальными вибраторами поддерживается Xorg'ом из коробки
9. множество видеокарт, включая только фреймбуферные поддерживаются Xorg'ом.
9.1 включая Xdummy (фиктивная видеокарта. поддерживает все расширения Xorg)
9.2 как в вайланде будут работать чисто framebuffer видяхи, в которых нет opengl-ускорителя? во встраиваемой техники таких большинство.
USB-видяхи вообще только так и работают.
10. сетевая прозрачность
11. при правильных настройках иксы и сейчас не тормозят. А при работе с opengl (при DRI) - тем более.
12. Можно отключить DRI, тогда opengl будет работать медленнее, но это будет безопаснее.
13. под Xorg есть такие расширения как:
13.1 Xdmx (можно несколько компов по сети в один дисплей объединить)
13.2 Xvfb/Xdummy
13.3 Xinerama
13.4 cromium (не путать с браузером)
13.5 XACE (был)
14. как заставить вайланд работать с 2-мя выводами видяхи, не говоря уже про две видяхи?

касаемо встраиваемой мебели/кондиционеров/пылесосов/холодильников: кроме Xorg есть и другие реализации X11, менее прожорливые.

И ещё:
1. X11 работает в Solaris, *BSD, QNX, MacOS, Windows, Linux, ReactOS, minix (частично на WinCE). Вайланд пока нигде не работает.
2. для X11 много серверов и всегда можно написать свой под ЛЮБУЮ ОС. А как с вайландом?

Ты ещё не понял, что разработчикам на твои потребности срать? У них планшеты в голове, а на планшетах большая половина из того, что ты написал не нужна, да и на ноутбуках в принципе тоже, а для остального и будут Иксы. Мультитач уже есть, несколько мониторов если и нет, то всё равно без них ничего не будет. А вот то, что это модуль ядра — это да, глупость.

1. X11 работает в Solaris, *BSD, QNX, MacOS, Windows, Linux, ReactOS, minix (частично на WinCE). Вайланд пока нигде не работает.

Дык потому оно ещё и в стадии разработки, не?

Ты эти потребности читал? Там какое-то отсутствие потребностей.

Нифига. Dash у меня и на открытом лагает! Там что-то адовое внутрях.

Не могу себе представить лагающую консоль.

кстати, а почему opengl es нельзя прям под иксами юзать? тогда все вяленые QT-приложения весьма шустро бы работали и на иксах.

KWin gles прекрасно под иксами бегает.