XFS must die?

> Скажите почему дистростроители отказываются от использования X Font Server'a (see Fedora 8/Mandriva 2008 release notes)?

на фига он нужен на одной тачке?

1) Как Core X (xlib based) приложениям сказать о новых директориях, содержащих шрифты, без редактирования xorg.conf?

mkfontdir /path/to/font/dir xset +fp /path/to/font/dir

2) Без понятия, не использую

3) ХЗ, поставь xfs сам

1) Как Core X (xlib based) приложениям сказать о новых директориях, содержащих шрифты, без редактирования xorg.conf?

mkfontdir /path/to/font/dir
xset +fp /path/to/font/dir

> дистростроители отказываются от использования X Font Server'a

Потому что нынешние "дистростроители" думают, что Иксы - это кеды с гномиком. Ну не прошли они в конце 1980-х - начале 1990-х школу распределенных иксовых UNIX-приложений. Сиё называется "писючковое мышление" (с). :)

+мильён

>Скажите почему дистростроители отказываются от использования X Font 
Server'a (see Fedora 8/Mandriva 2008 release notes)? Также возникают 
следующие вопросы:


То есть? Его теперь нельзя установить и запустить? В Debian Etch xfs 
идет отдельным пакетом, а не в составе xorg. Хочешь -- ставь, хочешь 
-- не ставь. Что-то я не уловлю никак проблему. К тому же, man xfs


FUTURE DIRECTIONS
       Significant  further development of xfs is unlikely.  One of the origi‐
       nal motivations behind it was  the  single-threaded  nature  of  the  X
       server  —  a  user’s  X  session  could seem to ‘freeze up’ while the X
       server took a moment to rasterize a font.   This  problem  with  the  X
       server, which remains single-threaded in all popular implementations to
       this day, has been mitigated on two fronts: machines have  gotten  much
       faster,  and  client-side  font  rendering  (particularly  via  the Xft
       library) is the norm in contemporary software.


То есть маятник качнулся в сторону client-side fonts. И уже давно.

> То есть маятник качнулся в сторону client-side fonts. И уже давно.

Причем совсем не в силу "писюкового мышления". Кстати, и системы на основе икс-терминалов сейчас вроде как вышли из моды, насколько я понимаю.

а каким терминалам тогда быть в моде? цытриксам за большие откаты?

>Причем совсем не в силу "писюкового мышления". Кстати, и системы на основе икс-терминалов сейчас вроде как вышли из моды, насколько я понимаю.

Они вышли из моды потому, что скорость работы по чистому X-протоколу на медленных соединениях гораздо ниже, чем в VNC и RDP. И многие из-за этого перестали рассматривать X-протокол. Но вот появился NX. И это тот же X-протокол, но специально пожатый, в котором, к тому же реализован обход latencies и прочие оптимизации. В итоге скорость получилась весьма высокой. Народ репортит, что быстрее VNC. Я сам пробовал сессию GNOME на скорости 56k -- работать вполне реально. Кто-то где-то написал, что nomachine.com вернули веру в X-протокол. Типа, забыли люди, что все задумывалось для сетевой прозрачности. :)

Вот тут документик хороший.

http://www.nomachine.com/documents/getting-started.php

Ну и, кстати, интересна на этот счет активность XCB в рамках fd.o. Как раз задумка была, чтобы заменить xlib и исключить latency.

Спасибо за информацию.

"Терминал не нужен". А если нужен - да, если угодно, цитрикс. Или rdp. Или (tight)vnc.

ЗЫ На самом деле, я, конечно, утрирую. Иксовые терминалы еще поживут маленько. Но вот рендерить шрифты на стороне иксового сервера - это слишком уж 90е (если вообще не 80е).

>3) Как теперь предполагается раздавать шрифты по сетке тонким клиентам?

xfs-ом и раздавать. Там уже просто нечего придумывать. Однако эта раздача остается актуальной только для софта на базе классики Motif, Xaw и т. д. Остальные клиенты уже все Xft используют. Самое главное здесь, что никто и ничего не отменяет. И эти методы рендеринга шрифтов (client-side и server-side) будут жить по-соседству. Я не пока не вижу причин, что кто-нибудь скажет, что старый способ будет отменен --- есть еще масса софта на Tcl/Tk, Motif, Lesstif, который работает на предприятиях. Да и просто старого софта, который не будет никем больше переписан.

Про fontserver ничего не скажу, а вот XFS, которая xfs- должна умереть... :)

Объясни, пожалуйста, как Xft может шрифты по сети передавать - я не въезжаю.

> Но вот рендерить шрифты на стороне иксового сервера

Вы точно уверены в формулировке? _cервера_ ?

X server - это на самом деле клиент ;-)

Наверное имелось в виду "на стороне сервера, на котором запущены иксы" :-)

>Объясни, пожалуйста, как Xft может шрифты по сети передавать - я не въезжаю.

Ну раньше X-клиенты вообще не работали с растеризацией шрифтов. Это делал шрифтовой модуль X-сервера или xfs (и по специальному каналу передавал это в X-сервер). Клиенты только запрашивали шрифт с нужной характеристикой (ну там кодировка, размер), а остальное делал сервер локально, либо получал отрендеренные битмапы от xfs. Но вот полутона не передавались, так как это не подаразумевается core протоколом. Еще раз: в X-сервер передавались только параметры шрифта, а не изображение. Так что если на X-сервере не было бы запрошенного шрифта, то он попросил бы его в xfs, получив битмап нужный.

Теперь же шрифт полностью растреризуется на стороне клиента, передается уже готовой картинкой, а на сервере рисуется (при помощи Render Extention или без него). То есть тебе фонт уже X-клиент готовеньким доставит. Можешь потереть все пути в xorg.conf, оставив только misc. Но шрифты Qt и GTK+ ты по-прежнему будешь видеть, а вот те приложения на Motif, которые используют какой-нибудь Terminus на тебя обидятся.

Поправочки.

>Так что если на X-сервере не было бы запрошенного шрифта, то он попросил бы его в xfs, получив битмап нужный.

Ну или, если нет xfs, подобрав наиболее подходящий из тех, что есть.

>а вот те приложения на Motif, которые используют какой-нибудь Terminus на тебя обидятся.

Показав все при помощи fixed, надо полагать. То есть не найдет terminus.

Смотри ситуацию. сидишь ты у себя, а X-клиент в Италии какой-нибудь, и там в приложении используется какой-нибудь ихний ItalianoSuperFont. Предположим, у тебя его нет ни на сервере, ни на xfs. В итоге никакого ItalianoSuperFont ты не увидишь у себя. Он будет заменен.

В случае ы client-side тебе приходит картинка (по X-protocol и Render Extension) того шрифта, который использует приложение. То есть ItalianoSuperFont ты увидишь.

Старое выкидывать никто не будет. А вот развития софта с серверным рендерингом не будет. xfs, может, жить и будет - но как показывает практика, не развивающийся софт = мертвый софт (довольно быстро)

Да, я уверен. X Server - это программа. Которая работает на клиентской стороне (перед непосредственным пользователем). И предоставляет services по графическому вводу-выводу (иногда еще и звуковому). Оные services используются приложениями-клиентами, запускаемыми на той же или на удаленных машинах.

>Старое выкидывать никто не будет.

Тем более, что оно никому не мешает. И уж более "тем более", что оно уж очень мого, кому требуется.

>А вот развития софта с серверным рендерингом не будет. xfs, может, жить и будет - но как показывает практика, не развивающийся софт = мертвый софт (довольно быстро)

А там просто уже нечего развивать. Можно сказать, что целей своих проект достиг (ну разве что AA не заполучил). Significant further development of xfs is unlikely. Ну, значит, незначительное будет: правка сборки и пр.

Ну вот у меня есть эмулятор Commodore 64 (называется VICE). Так он сделан на Xaw. Я сомневаюсь, что его кому-то в голову придет переписывать на GTK+, так как там только менюхи. Остальное -- графика. Или xmessage, например, которые много, кто использует. Никто же не будет эту бусиночку переписывать с громадиной Qt :). А основной разработчик PCB пишет свою ветку исключительно на lesstif, и хоть ты тресни, но веткой -gtk не занимается. Так что все старые методы server-side fonts поживут, пока кто-то не переведет Xaw и Lesstif на Xtf или не перепишет софт. Вон недавно была новость, что в Motif наконец-то в 2007 году приделали Xft :) Дождались :)

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

>я на эту тему тут уже чуть-чуть высказывался, система xfs мне как-то больше нравится. например, что предлагается делать при использовании xft в случае большого парка компьютеров?

В случае использования Xft, xfs уже не нужен в принципе. xfs -- это исключительно X-сереверу для server-side fonts нужно. xfs была нужна, чтобы раздать терминалам шрифты, доступа к которым у них нет. А в случае с client-side fonts, X-серверу вообще доступ к шрифтам не нужен. Главное, чтобы у X-клиентов доступ был к шрифтам, то есть там, где программа физически работает, а это уже не проблема.

Таким образом, если на терминале требуются приложения, которые работают с server-site fonts, то им мы поднимаем xfs. Остальным (т. е. приложениям с Xft) этого не требуется вообще.

>но неужели его никак нельзя доработать под новые реалии?

Еге *не надо* дорабатывать под новые реалии. Новые реалии без xfs работают.

Насколько я понимаю, вопрос был такой - нельзя ли убедить Xft (на клиентах!) брать шрифты не локально с диска (ну, пусть сетевого), а по специально заточенному протоколу со шрифт-сервера. Вроде, на сегодня ответ "нет".

Как тогда шрифты раздавать? Через SMB/NFS шару? Во, маразм.

>Насколько я понимаю, вопрос был такой - нельзя ли убедить Xft (на клиентах!) брать шрифты не локально с диска (ну, пусть сетевого), а по специально заточенному протоколу со шрифт-сервера. Вроде, на сегодня ответ "нет".

Ну я пока не совсем понимаю, зачем? Ведь Xft нужен, собсвенно сам файл шрифтов. А xfs растеризовывал *вместо* X-сервера. То есть это был как бы кусок его кода, но только удаленный. Поэтому и отдельный канал рисовали, чтобы растеризованный шрифт гнать назад. А сейчас же шрифт растрезированный -- это обычный X-протокол, которому не нужен отдельный канал. Так что сейчас задача состоит в том, чтобы дать Xft доступ к *файлу*. А чем сетевой диск плох? Городить еще один способ доставать файлы шрифтов по сети, специально ориентрованный на Xft? А не получим опять сетевой диск, но только переизобретенный?

>Как тогда шрифты раздавать? Через SMB/NFS шару? Во, маразм.

Раздавать кому? X-серверу или X-клиенту? У тебя X-клиенты на скольких компьютерах будут? Я, полагаю, что на одном? Тогда зачем тебе одному компьютеру раздвать шрифты? А X-серверам они придут уже в составе X-протокола. Тебе для X-серверов не нужен раздатчик (в случае Xft). Все уже искаропка придет. Твоему серверу останется только изобразить на экране. А если тебе старые программы (типа xpdf) надо, то поставь на стороне X-клиента xfs, укажи пути. А в X-серверах в FontPath укажи, откуда отрендеренные битмапы придут. И все.

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

Что-то всё очень сложно получается. Раньше указал в пути X Server'a unix:7100 или IP_Address:7100 и всё.

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

Ну так а какие сейчас проблемы? Шрифт не надо раздавать теперь. Тебе приходит он уже готовый, отрендерненный в X-протокол, в том внешнем виде, в котором его использует X-клиент. А для старых тулкитов поставь xfs. Новым просто он уже не нужен уже. Если у тебя на тонком клиенте нет Render, то Xft по-умному рендерит шрифт в core X-protocol без Render. То есть все старые реализации X-серверов будут работать. Обратная совместимость сохраняется.

>Что-то всё очень сложно получается. Раньше указал в пути X Server'a unix:7100 или IP_Address:7100 и всё.

Ну так а теперь не надо и этого. Теперь вся та информация, которая шла через IP_Address:7100 идет по каналу с X-протоколом вместе со всей остальной информацией по отрисовке окон и пр.

Всё ясно, спасибо.

> Городить еще один способ доставать файлы шрифтов по сети, специально ориентрованный на Xft? А не получим опять сетевой диск, но только переизобретенный?

Да, об этом я и говорю - о доп. протоколе под Xfs. Не думаю, что мы получим сетевой диск. И вот почему - поддержка файловой системы требует нехилого кол-ва накладных расходов, которые могут оказаться ненужными в случае со шрифтами. Опять же, в дальнейшем можно наворачивать такие вещи как "доступ к лицензионному защищенному шрифту СуперГотик разрешен не более чем 5 приложениям одновременно". Или "запретить доступ к шрифту МегаБолд со станции 192.168.1.11"

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

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

Я предполагаю, что существуют более легкие способы пробиться к файлам помимо NFS/SAMBA/FTP. Это уже дело архитектора терминальной системы, как ему поиметь доступ к хранилищу шрифтов более простым способом. fd.o вряд ли будут рассматривать возможность какой-то доморощенной реализации расшаривания шрифтов конкретно для букаф.

> fd.o вряд ли будут рассматривать возможность какой-то доморощенной реализации расшаривания шрифтов конкретно для букаф.

Согласен. Именно потому что спрос на такие решения ничтожный.

>Опять же, в дальнейшем можно наворачивать такие вещи как "доступ к лицензионному защищенному шрифту СуперГотик разрешен не более чем 5 приложениям одновременно". Или "запретить доступ к шрифту МегаБолд со станции 192.168.1.11"

Такую задачку, как мне кажется, не решить на уровне раздатчика на стороне X-клиента, потому что раздатчик никак не может знать, какая программа-клиент для какого X-сервера просит шрифт. Шрифт просто просят: "Дай файл!". А могут ведь даже и не попросить, так как что-то кешируется, наверное, на уровне растеризатора. Так что разграничение прав должно решаться максимум на уровне Xft (fontconfig?) и ниже, чтобы он для определенных терминалов просил определенные шрифты или рендерил в поток любой другой из разрешенных. Задача нехилая. И я не уверен, что сильно нужная. В любом случае, там писанины немало будет. Ну это так, навскидку.

> не решить на уровне раздатчика на стороне X-клиента, потому что раздатчик никак не может знать, какая программа-клиент для какого X-сервера просит шрифт

Насколько я знаю, на клиенте вроде нет никакого "раздатчика". Есть только приложение (допустим, gedit), которое через стек библиотек (допустим, gnome/gtk/gdk) использует библиотеку xft. Т.е. вполне реально узнать, какое приложение запрашивает шрифт (все это в одном процессе живет). Кеширования между запусками приложений там, вроде, тоже не было.

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

>Т.е. вполне реально узнать, какое приложение запрашивает шрифт (все это в одном процессе живет).

Да, но нам нужно знать не приложение, а адрес терминала, куда пойдет изображение шрифта. Раньше все было понятно, так как терминал (X-сервер) сам обращался за растеризацией к xfs, и xfs знал *кто* к нему пришел. а сами изображения шрифтов гонялись независимо от X-протокола. А теперь X-сервер *сам* ничего не просит. Просит приложение, которое может быть использовано разными терминалами. Поэтому для Xft -- это вызов от просто безымянный вызов от Gtk без конкретизации терминала.

>Кеширования между запусками приложений там, вроде, тоже не было.

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

> а адрес терминала, куда пойдет изображение шрифта

Фигня вопрос. Грубый ответ - getenv("DISPLAY"). Точнее - вроде, можно как-то при помощи иксового API узнать.

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

Это понятно. Но это только пока процесс работает. Очевидно, что если процессу дали доступ к шрифту - его уже нельзя "отобрать". А вот не дать приложению этот шрифт при следующем запуске - очень даже можно.

>Фигня вопрос. Грубый ответ - getenv("DISPLAY"). Точнее - вроде, можно как-то при помощи иксового API узнать.

Ага. Ну вот и получается, что надо это вделывать либо в Xft (что лучше -- поглобальнее), либо в приложение (что хуже). О чем я и говорил: "максимум на уровень Xft и ниже". И делать специальный файл по разграничению прав на шрифты. Если эта задача вот так вот решается, то это уже не так глобально сложно при появившейся необходимости.

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

Можно и "отобрать", если добавить правило на уровне Xft на запрет доступа и закоммитить его, не перезапуская приложение. Ну типа, как обновление font.conf работает по таймеру. Тогда даже, если шрифт был закеширован, то Xft даже кеш использовать не будет.

Ну да, можно и так усложнить. Осталось только придумать, кому и зачем нужны такие сложности;)