Почему X-оконная система использует сервер?

Это зависит от Вашей оболочки при использовании удара @Dennis, является абсолютно правильным, для zsh это может быть другая проблема, если Вы включили EXTENDED_GLOB в этом случае ^ интерпретируется оболочкой, и необходимо заключить ее в кавычки, т.е.:

alias ggg='alias | grep "^g"'
25
06.10.2014, 11:40
6 ответов

Я думаю, что вы уже заметили, что необходим какой-то «сервер». Каждый клиент (среда для рабочего стола, оконный менеджер или оконная программа) необходимо поделиться дисплеем со всеми остальными, и они должны иметь возможность отображать вещи, не зная деталей оборудования, или знание того, кто еще использует дисплей. Таким образом, сервер X11 предоставляет слой абстракции и совместного использования, который вы упомянули, предоставляя интерфейс IPC.

X11, вероятно, может быть сделан для проведения по именованным трубам, но есть две большие вещи, которые называются трубы, не могут сделать.

  • названные трубы общаются только в одном направлении.
  • Если два процесса начинают начать данные в «отправку» конце с именованной трубы, данные будут проходить в смешенные.

На самом деле, большинство X клиентов разговаривают с сервером, используя «новую и улучшенную» с именованной трубой «новую и улучшенную», называемую розетку Unix домена. Это очень похоже на названную трубу, за исключением того, что она позволяет процессам разговаривать в обоих направлениях, и оно отслеживает, кто сказал, что. Это одинаковые вещи, которые необходимо сделать сеть, и сокеты UNIX-домена используют один и тот же интерфейс программирования, что и сокеты TCP / IP, которые обеспечивают сетевые коммуникации.

Но оттуда можно легко сказать «Что, если я провел сервер на другом хосте, чем клиент?» Просто используйте разъем TCP вместо сокета UNIX и VOILA: протокол удаленного рабочего стола, который предложен Windows RDP в течение десятилетий. SSH SSH к четырем различным удаленным хостам и запущению Synaptic (графический пакет Manager) на каждом из них, и все четыре окна появляются на дисплее моего локального компьютера.

39
27.01.2020, 19:40

X был изначально разработан и поддерживался M.I.T. И, это было с лицензией M.I.T. с открытым исходным кодом, не то, чтобы это действительно имело значение.

Хотя это и считается нетрадиционным, подумайте на мгновение; как бы вы объяснили выбор применения парадигмы "клиент-сервер" в программном продукте? И, возможно, мне следует сказать генеральному директору...

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

Хотя на самом деле это и не так, но оконный менеджер часто объясняют так: Это просто, эта штука, которая помещает ручки и другие украшения в рамку приложения, а также окна, диалоги и т.д.

2
27.01.2020, 19:40

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

  • Ресурс может управляться ядром, а приложения для доступа к нему обращаются к ядру.
  • Ресурс может управляться выделенным процессом (сервером), и приложения обращаются к серверу для получения доступа к нему.

Конечно, доступ к реальному оборудованию отображения контролируется ядром, но этого недостаточно для системы отображения окон: Должен быть способ, чтобы процессу была назначена определенная часть дисплея (окна), где он может быть уверен, что никакой другой процесс не будет вмешиваться, и должен быть определенный уровень защиты того, какое приложение может получить доступ к какой части рессурса в какой момент времени.

Теперь все это могло бы уйти в ядро, которое является AFAIK тем, что делает Windows. Преимущество такого подхода в том, что он быстрее (обычно вызов ядра происходит гораздо быстрее, чем обращение к другому процессу), но у него есть и недостаток, заключающийся в том, что он, возможно, открывает дыры в безопасности (любой эксплойт системы - это эксплойт на уровне ядра), и в то же время ограничивает переносимость (система, реализованная в ядре, сильно связана с ядром; вы не сможете легко перенести ее на другую операционную систему, и полностью не сможете этого сделать, если у вас нет доступа к коду ядра).

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

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

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

7
27.01.2020, 19:40

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

Названные трубы не дадут вам автоматическое преимущество в том, что он может пройти через сеть в качестве реализации TCP. Но именованные трубы были E.g. Недоступно в DOS, с DOSEXTENDER RONGE DESQVIEW / X (1992) и AFAIK также не на VMS. Для этих реализаций является проблемой конкретная связь Unix.

TCP не является конкретным UNIX, и в 1984 году в 1984 году можно запустить клиентский запуск клиента в 1984 году) и служению вывода на вашу локальную графику на основе Unix. Из «Оконная система X: Полная ссылка на XLIB, X протокол, ICCCM, XLFD "¹:

Во время осени 1986 года Цифровой решил основывать всю стратегию рабочего стола на рабочем месте для Ultlix, VMS и MS-DOS на X. Хотя это было удовлетворено нам, это также имел в виду, что у нас было еще больше людей, чтобы поговорить. Это привело к некоторой задержке, но, в конце концов, Это также привело к лучшему дизайну. Ральф Увик цифрового присоединения проекта Афина во время Этот период и сыграл жизненно важную роль, чем разработка версии 11. Последний вер- Выпуск Sione 10 был доступен в декабре 1986 года.

из «Руководства справочного руководства X протокола» ²:

Отделение обязанностей

в процессе проектирования протокола X, большая мысль попала в разделение возможностей между Сервер и клиент, SIND Это определяет, какая информация должна быть передана взад и вперед через запросы, ответы и события. Отличным источником информации о обосновании определенных вариантов, сделанных в проектировании протокола, является статья «Оконная система X Robert W. Scheifler и Jim Gettys, опубликованная в ассоциации вычислительной техники журнала Transcation на графике, Vol 5, Нет. 2, апрель 1986 г. Решения в конечном итоге достигали, были основаны на переносимости клиентских программ, простотой клиентского программирования и производительности.

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

Я помню статью в Тоге, будучи интересным чтением. Это, безусловно, вызвало мой интерес к X и (это было до всемирного worldwideweb) трудности, которые мы выкладываем свои руки на дополнительную информацию до тех пор, пока О'Ррили не начал публиковать свои серии X книги.

¹ x версии 11, выпуск 4, Page 2-X, PDF доступны в Интернете здесь
² Это из Page 9 в 2-м издании, опубликованном O'Reilly, что Я купил в 1990 году. Есть новые издания, но я никогда не удосужился покупать их, и они афаик также доступны в статье. Я не думаю, что они изменили обоснование отдела ответственности.

14
27.01.2020, 19:40

Не знаю о других системах Debian (wheezy )/или Ubuntu (14,10.), но я проверяю такие проблемы с помощью простой старой команды file .

file /sbin/init

дайте следующее:

/sbin/init: symbolic link to 'upstart'

Системы Debian с systemd (например, sid) показывают следующее:

# file /sbin/init 
/sbin/init: symbolic link to /lib/systemd/systemd
-121--3992-

Из Debian Wiki :

С момента 2,4,23-3 версии конфигурация OpenLDAP была изменена на/etc/ldap/slapd.d по умолчанию.

Таким образом, OpenLDAP позволяет динамически настраивать себя через дерево 'cn = config' .

DN можно вывести в cn = config и увидеть следующее:

sudo ldapsearch  -Y EXTERNAL -H ldapi:/// -b cn=config dn
...
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
...

sudo ldapsearch  -Y EXTERNAL -H ldapi:/// -b cn=config 'olcDatabase={1}hdb'

# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=nodomain
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
 s auth by dn="cn=admin,dc=nodomain" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=nodomain" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=nodomain
olcRootPW: {SSHA}_skip_
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq

Атрибут olcAccess - это то, что вам нужно.

Добавим новые правила ACL в базу данных dc = nodomain .

Создать ldif-файл

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to dn.base="cn=test,dc=nodomain" by * read

Применить:

sudo ldapmodify  -Y EXTERNAL -H ldapi:/// -f /tmp/test.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"

Voilà:

sudo ldapsearch  -Y EXTERNAL -H ldapi:/// -b cn=config 'olcDatabase={1}hdb'
...
olcAccess: {3}to dn.base="cn=test,dc=nodomain" by * read
-121--52915-

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

Хотя есть много способов связи между сервером и клиентом, выбор, сделанный X (независимо от преимуществ, упомянутых другими), не лишний: можно подключиться к серверу X на другом компьютере и открыть окна на рабочем столе (или на другом сотрудничающем рабочем столе). Это было очень часто во времена разработки X, когда многие университеты и предприятия имели сервер Unix и множество «X терминалов,» которые разговаривали с ним. С помощью протокола связи, готового к подключению к Интернету, X можно легко использовать внутри хостов или между ними.

X была первой средой графического интерфейса пользователя, которая могла прозрачно отображать окна с другой машины, в соответствии с историей UNIX как многопользовательской среды, а не ОС для одного пользователя на одном компьютере. Многие функции UNIX кажутся избыточными, если вы единственный человек, который когда-либо может взаимодействовать (физически или удаленно) с вашим компьютером.

0
27.01.2020, 19:40

Я считаю, что X-Server был разработан в качестве архитектуры клиент-сервер, поскольку изначально вычисляющие ресурсы были дефицитными, а основныефреймы не имеют большую часть тяжелой подъема. X-Terminals были просто тонкими клиентами, которые подключались к X-серверам и отображают все, что необходимо для отображения пользователю.

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

-1
27.01.2020, 19:40

Теги

Похожие вопросы