Критика X.org/XFree

> Хинт: таки время от времени сохранять посчитанные a_i, например, на диск.

Илия гоню или о сетевом сторадже речь и шла ?

Да перенесут интерфейс графики, куда денутся. EFI будет, поддержка его - в ядре будет, драйвера EFIшные будут - куда деваться, потребуется ядерный интерфейс..

>>>в угоду разработчиков проприетарных драйверов от nVidia и ATI API/ABI интерфейсы

Нету в письме ничего про API/ABI. И слов таких не упоминается.

>На вскидочку /usr/X11R6 /usr/xorg ?

не угадал. Дабы тебя успокоить, могу сказать, что их там вообще нигде нет. Иксы - они только на терминалах. Будешь хакать терминал? А зачем, можно спросить? :)

>> Хинт: таки время от времени сохранять посчитанные a_i, например, на диск.

> Илия гоню или о сетевом сторадже речь и шла ?

Или свои сообщения почитай внимательно?

На этот storage данные будут святым духом записываться ?

> вдруг твой браузер упал (это клиент).

Не вижу даже близкой аналогии.

На Х сервере я пускаю xterm (с тонкого клиента) Какую libX<чего нибудь> он подгрузит ? Мою ? Ничего не путаем ?

> Будешь хакать терминал? А зачем, можно спросить? :)

Бугога, шоб нарисовать на твоем X-терминале голую бабу :)

They don't want to change how X works, because it would break the vendor binary drivers from ATI and NVIDIA

>На Х сервере я пускаю xterm (с тонкого клиента) Какую libX<чего нибудь> он подгрузит ? Мою ? Ничего не путаем ?

А xterm на тонком клиенте не запустишь, нету его там..

>А xterm на тонком клиенте не запустишь, нету его там..

В догонку, X сервер это и есть тонкий клиент.

Ну, и где тут написано про Application Programming Interface, про который birdie чирикал?

>На Х сервере я пускаю xterm (с тонкого клиента)

>Какую libX<чего нибудь> он подгрузит ? Мою ?

libX* лежащую на сервере. И? как libX* взаимодействуют с X11-сервером, знаешь? :)

test@dap:~/xmodulepath$ ./root.sh
/bin/rm -f exploit.o exploit.so shell *.o *.so
gcc -fPIC -c exploit.c
gcc -shared -nostdlib exploit.o -o exploit.so
gcc -o shell shell.c
X: user not authorized to run the X server, aborting.


[*] Executing shell with uid=1002 and euid=1002

shell # id
uid=1002(test) gid=1002(test) группы=1002(test)
shell # tail /var/log/messages
tail: невозможно открыть `/var/log/messages' для чтения: Permission denied
shell # X :1.0
X: user not authorized to run the X server, aborting.

и?

> Или свои сообщения почитай внимательно?

А во теперь понял... Извини это я вчера по пиву перестарался вообще-то я как раз о необходимости сохранения на внешенем ресурсе и говорил.

> И? как libX* взаимодействуют с X11-сервером, знаешь? :)

Локально после чего эта связочка отдаст айпями на клиента очередь сообщений

>Локально после чего эта связочка отдаст айпями на клиента очередь сообщений

не локально, а через сокеты. Разницу чуешь? libX* на одном хосте, а X-сервер - на другом (на терминале). Дальше будешь хакать тонкие клиенты, или почитаешь таки документацию? :)

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

Мы разрешаем одновременно только одному root-процессу работать с регистрами. Это слабое решение, но это лучшее, что мы можем сделать.

Позвольте мне выразиться яснее - я считаю, что разработчики X - свора бесстыжих декоративных песиков, заискивающих перед вендорами, которые, я уверен, не торопятся с решением этой проблемы, которой уже 10 лет! Они тратят больше времени на поддержку последних бинарных загружаемых драйверов от продавцов железа, чем на решение этой очевидной проблемы. (Перевод: Они не хотят изменить принцип работы X сервера, потому что это нарушило бы работу бинарных драйверов от ATI и NVIDIA. Это - часть того, что бывает, когда разработчики X получают рабочие места у вендоров).

Наконец вспомнил свой пароль:) Ну и где здесь про API/ABI? Здесь как раз про sysctl, который очень даже не плох, тем что сам интерфейс стандартизирован. И опять же сплошное хамство - разработчиков иксов сворой шавок назвал. Авторитет, блин.

> не локально, а через сокеты.

Так! Давай по порядку (предлагаю без резкозтей) На клиенте(чтобы не было путанницы назовем ее рабстанцией) установлен лишь X "знающий" видяху/мышь/клавиатуру и пускающий X -query desktop_server.org. При подключении подымается *dm'у отдается дисплей на рабстанции только для прорисовки виджетов и в свою очередь от рабстанции принимаются сообщения о смене состояния (мыши/клавы). Используется память/цпу только сервера - рабстанция всего лишь пустой терминал.

s/подымается//

Я малость отвлекусь - до дому доеду...

http://en.wikipedia.org/wiki/X_Window_System
http://ru.wikipedia.org/wiki/X11
http://ru.wikipedia.org/wiki/Тонкий_клиент

Шутка в том, что _принципиально_ Тео прав.
Но пока у нас нет альтернативы чем заменить X. И не предвидится. Так что сопли и вопли Тео не дадут ничего.

http://en.wikipedia.org/wiki/X_Window_core_protocol

>Наконец вспомнил свой пароль:) Ну и где здесь про API/ABI? Здесь как раз про sysctl, который очень даже не плох, тем что сам интерфейс стандартизирован. И опять же сплошное хамство - разработчиков иксов сворой шавок назвал. Авторитет, блин.

Торвальдса не желаешь вспомнить? Тео еще святой по сравнению с ним.

>Так! Давай по порядку (предлагаю без резкозтей) На клиенте(чтобы не было путанницы назовем ее рабстанцией) установлен лишь X "знающий" видяху/мышь/клавиатуру и пускающий X -query desktop_server.org. При подключении подымается *dm'у отдается дисплей на рабстанции только для прорисовки виджетов и в свою очередь от рабстанции принимаются сообщения о смене состояния (мыши/клавы). Используется память/цпу только сервера - рабстанция всего лишь пустой терминал.

таким образом ты запустил X-server на рабстанции, а dm является клиентом, который говорит по сети, что X-server должен нарисовать в окне. Все уязвимости в багтраке с 2003 года приводят к краху X-server на рабочей станции при этом клиент не затронут, за исключением одной где клиенту можно xfs подставить другой. Обмена библиотеками нет, только данные.

>Обмена библиотеками нет, только данные.
Подожди, он домой доедет, ссылки почитает :-)

>Подожди, он домой доедет, ссылки почитает :-)

Когда человеку толдычат уже 3-тью страницу одно и тоже, начинает утомлять. Сомневаюсь, что такие люди ссылки читают.

>а dm является клиентом, который говорит по сети, что X-server должен нарисовать в окне.

О чем и говорилось. Допустим уязвимость в Xpm (кажется гипотетическая) кого "сложит" ? ИМХО всетаки сервер а не рабстанцию, поскольку последняя получит ее как битмат, как в принципе любое приложение для нее не более чем кавадратный регион гд-шку которого надо отрисовать...

А то в свете ваших постов получается что скажем если я с клиента у которого Xы работают через fb вместо шестеренок glxgears должен буду увидеть черное пятно.... Все отрендерится и отрисуется на сервере... не на рабстанции.

Это я был просто не подписался...

>поскольку последняя получит ее как битмат, как в принципе любое приложение для нее не более чем кавадратный регион гд-шку которого надо отрисовать...
Боже, ниспошли на его "кавадратный регион", в простонародье именуемый "голова" умение нажимать на ссылки и дай ему возможность осознания того, что протокол X11 может дополняться расширениями (в частности, GLX).
>А то в свете ваших постов получается
Не смотри сквозь призму наших постов, загляни в документацию :-)

> умение нажимать на ссылки

На википедию ? Мне хватает sgi-шного туториала

Вы практически все правильно пишете, но никакие битмапы между клиентом и сервером не курсируют. Есть х-протокол и команды этого протокола. У вас есть сервер, запущенный на рабочей станциии, который получает команды от клиентов, работающих на сервере. Т.е. Х-сервер все же жрёт циклы и память на рабочей станции. Более того практически все Х-ресурсы тоже хранятся на Х-сервере. а у клиента имеется только идентификатор X-ресурсов. Общение между клиентом и сервером выглядит как-то так - клиент командует серверу нарисуй линию с такими-то координатами ,используя цвет и перо из ресурса с таким-то номером. Что Х-сервер и делает. Но при этом растеризует линию сам Х-сервер, а не клиент.

> Но при этом растеризует линию сам Х-сервер, а не клиент.

Это справедливо только для графических примитивов. И кажется (не уверен) для Xaw. Все остальное - будет отдаваться не имначе как битмапы. Cм пример с glxgears

>>Cм пример с glxgears

То же самое. Есть расширение Х-протокола (добавочный набор команд) - GLX. С помощью этого расширения клиент даёт понять серверу, что тому нужно отрисовать картинку, используя OpenGL.

> Но пока у нас нет альтернативы чем заменить X.

SVGAlib? фреймбуфер ? ANSI терминал 80x25 ? а, ну конечно - паранои ^W безопасники и там найдут последовательности переназначения клавиш. Надо сделать mesg off и пользоваться dumb-АЦПУ с листом бумаги, а ещё лучше - печатающей машинкой.

>О чем и говорилось. Допустим уязвимость в Xpm (кажется гипотетическая) кого "сложит" ? ИМХО всетаки сервер а не рабстанцию, поскольку последняя получит ее как битмат, как в принципе любое приложение для нее не более чем кавадратный регион гд-шку которого надо отрисовать...

чтобы окончательно отмести все сомнения можно вспомнить, что все эти уязвимости в общем направлены на либо повышение привилегий либо на DOS. В связке X-server (тонкий клиент, рабстанция) и X-приложение (сервер) повышенными привелегиями обладает X-server, а X-приложение запускается от обычного пользователя.

Raad метко подметил, что получается в юниксе две программы работают напрямую с железом . Странно ,что 30 этого не замечали.Предложений тогда -два -или сделать как в досе -чтобы каждая программа могла работать напрямую с железом -для убыстрения всех программ , либо сделать какую-либо нормальную ОС в которой все обращения к железу проверяет ОС(корректность и правомерность).Или третье -пусть всё остаётся на месте и глючит дальше.

>Raad метко подметил, что получается в юниксе две программы работают напрямую с железом . Странно ,что 30 этого не замечали.Предложений тогда -два -или сделать как в досе -чтобы каждая программа могла работать напрямую с железом -для убыстрения всех программ , либо сделать какую-либо нормальную ОС в которой все обращения к железу проверяет ОС(корректность и правомерность).Или третье -пусть всё остаётся на месте и глючит дальше.

а также софт модемы, wi-fi, часть принтеров, сканеров, новомодный инфинибанд и т.д. и т.п.

Конечно давай всех под одну гребенку!

Надо просто понять и принять, что иногда приходится делать исключения.

Когда иксовое приложение выводит в свою гдшку битмап размером AxB - это никак не AxB событий пера. Это именно битмап. Элементарно что qt что gtk не используют при отрисовке Xdraw-функции - строго манипуляции с битмапами Так что... Еще как летают.

Кстати про glxgears аргумент снимается - был не прав. Отрисовывается локально софтверно... мезой... Просто включен экстэншн был.

Программ которые работают с железом напрямую сильно больше, чем две. Какие-то манипуляции с портами ввода вывода, памятью устройств можно делать из user-space, но разумеется под рутом. Странно думать, что кроме Х-сервера этими возможностями никто не пользуется. Взять хотя бы вышеупомянутую svgalib.

>Это справедливо только для графических примитивов. И кажется (не уверен) для Xaw. Все остальное - будет отдаваться не имначе как битмапы. Cм пример с glxgears
Не уверен, не говори.
Запусти с двух разных X-терминалов (с поддержкой GLX и без)
ssh -X user@host /usr/X11R6/bin/glxgears -info и офигей :-)

>Кстати про glxgears аргумент снимается - был не прав. Отрисовывается локально софтверно... мезой...
Отрисовывается локально, но не обязательно месой, а вендором GLX.

> И вообще, он добрый, отзывчивый человек. А ведь некоторые "гуру" считают ниже своего достоинства ответить новичку:

> Date: Mon, 25 Nov 2002 08:42:57 -0700 From: Theo de Raadt <deraadt@cvs.openbsd.org> To: Andrew Back <andy@smokebelch.org> Subject: Re: Syslogd +XML

> Go to hell.

Блин, ну и ржак!

Вы все же прочитайте внимательно Blue Book, раз она вам так нравится. Битмап - это тоже x-ресурс. Он генерится на сервере и приложению возвращается идентификатор ресурса. Потом приложению достаточно послать этот идентификатор на сервер, чтобы тот понял какой именно требуется битмап.

>Какие-то манипуляции с портами ввода вывода, памятью устройств можно делать из user-space, но разумеется под рутом Неужели? В защищенном i386 режиме процессора? Только из нулевого уровня исполнения, но никак не из userspace. Твой процесс может писать тольк в пул памяти, выделенный конкретно для твоей задачи. Как ты собираешься писать в пространство памяти ядра?

Таблица базовых адресов (ТАБЛИЦА ДЕСКРИПТОРОВ) может быть ЛОКАЛЬНОЙ (Local Descriptor Table) - кодируется TI=1 и ГЛОБАЛЬНОЙ (Global Descriptor Table) TI=0. Таблица дескрипторов помимо базового физического адреса содержит информацию, описывающую адресуемый сегмент. Глобальная таблица используется операционной системой и она должна существовать в одном варианте, а локальная создается для каждой прикладной программы отдельно. Таблица может иметь размер от 8 байт до 64 Кбайт и содержать до 8192 дескрипторов. Как адресовать память ядра???

Кстати, 64K портов ввода-вывода это тоже область памяти ядра.

Я отхватил себе диапазон портов с помощью ioperm - и после этого мне что-то может помешать делать с ними все что мне вздумается?

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