Опубликованы результаты голосования среди гномеров по поводу DVCS

> Но тем самым убивается Ваша ключевая позиция - совместимость. Ибо старые приложения, не использующие это расширение, вылетают в трубу по параметру "время запуска".
Для gui-приложения время запуска не играет никакой роли. Что 10 миллисекунд, что одна секунда -- всё одно. Самый большой затык всё равно происходит при передаче нервных импульсов в мозгу пользователя.

> Таким образом, остается один козырь - одинаковый внешний вид приложений с разных хостов. Но у этой фичи копеечный приоритет.
Мне скопипастить сюда весь список козырей server-side? Или будем продолжать упорствовать, называя унификацию внешнего вида единственной фичей?

> Кстати, напоминаю - xft справляется работать и без "своего" расширения, только не так красиво. Тогда как без расширения "частичная загрузка метрик" приложения будут стартуют слишком долго.
Я так вижу ещё и оценка этого "слишком долго" имеется?

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

> Мне скопипастить сюда весь список козырей server-side?
Из того pdf? Остальные там еще менее актуальны. А вот упомянутая выше необходимость иногда засылать глифы в неизвестном заранее формате - ее куда девать?

> потом получаем затык при каждой отрисовке текста
С чего бы?

>> Мне скопипастить сюда весь список козырей server-side?
> Из того pdf? Остальные там еще менее актуальны.
Кеширование глифов неактуально? Фонт-сервер неактуален?
Для тех, у кого одиноко в лесу стоит десктоп, это действительно неактуально.

> А вот упомянутая выше необходимость иногда засылать глифы в неизвестном заранее формате - ее куда девать?
Что?

>> потом получаем затык при каждой отрисовке текста
> С чего бы?
С того, что когда server!=client, передавать кучу битмапов становится "слегка" дороговато.

> Для тех, у кого одиноко в лесу стоит десктоп, это действительно неактуально.
Не одиноко в лесу, а хотя бы 90% приложений - локальные. А на обычном десктопе это именно так.

Кстати, попытка открыть еще один мини-тред. Как насчет wysiwyg в случае серверного рендеринга? Печать будет использовать одни шрифты, экран - другие? Как предлагаете решать?

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

> С того, что когда server!=client, передавать кучу битмапов становится "слегка" дороговато.
С чего бы "кучу"? Битмап один, с полной картинкой (той области, которую надо перерисовать).

>> Для тех, у кого одиноко в лесу стоит десктоп, это действительно неактуально.
> Не одиноко в лесу, а хотя бы 90% приложений - локальные. А на обычном десктопе это именно так.
Десктоп --- наиболее убогий способ использования графической подсистемы unix.
Ещё один хороший вид стандартного её использования --- терминалы. Там 100% приложений локальные. А в ltsp есть такая стандартная фича "local applications", в результате чего получается смешение локальных и удалённых приложений.

> Кстати, попытка открыть еще один мини-тред. Как насчет wysiwyg в случае серверного рендеринга? Печать будет использовать одни шрифты, экран - другие? Как предлагаете решать?
Эту проблему уже решали и до появления xft.

>> С того, что когда server!=client, передавать кучу битмапов становится "слегка" дороговато.
> С чего бы "кучу"? Битмап один, с полной картинкой (той области, которую надо перерисовать).
Это куча. Во всяком случае, с точки зрения пропускных способностей канала.

> Десктоп --- наиболее убогий способ использования графической подсистемы unix.
Тем не менее цель Гнома и КДЕ - именно оно. Соответственно выбираются приоритеты. Да, и в fd.o вторая буква именно desktop. Вы же ругаетесь на то, что десктоп строит себя именно исходя из приоритетов для десктопа. Не глупо ль?

> Эту проблему уже решали и до появления xft.
Как? Я помню древний StarOffice - какой там был грязный секс с установкой шрифтов. Кажется, там специальная утилита была... Да, слово XPRINT в приличном обществе не произносить!

> Это куча.
Если один - это куча, то что ж тогда не куча??? Вообще ничего не пересылать?

>> Десктоп --- наиболее убогий способ использования графической подсистемы unix.
> Тем не менее цель Гнома и КДЕ - именно оно. Соответственно выбираются приоритеты. Да, и в fd.o вторая буква именно desktop. Вы же ругаетесь на то, что десктоп строит себя именно исходя из приоритетов для десктопа. Не глупо ль?
Как бы за то и ругаю.

> Да, слово XPRINT в приличном обществе не произносить!
Ну да, его ж гном не поддерживает, потому оно неправильное. :о)

>> Это куча.
> Если один - это куча, то что ж тогда не куча??? Вообще ничего не пересылать?
Разницу между текстом и картинкой не ощущаешь?

> Как бы за то и ругаю.
За то, что сообщество, которое хочет делать нечто, делает именно это - а не что-то другое? Очччень умно. Особенно если учесть, что именно это делать актуально и востребовано.

> Ну да, его ж гном не поддерживает, потому оно неправильное. :о)
XPRINT умер еще до гнома. Но все-таки, какие будут предложения по организации WYSIWYG при серверных шрифтах? Или только XPRINT?

> Разницу между текстом и картинкой не ощущаешь?
На 100М и гигабитных сетях - не очень.

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

>> Ну да, его ж гном не поддерживает, потому оно неправильное. :о)
> XPRINT умер еще до гнома.
Неужели? Не он ли в ноябре прошлого года обновлялся?

> Но все-таки, какие будут предложения по организации WYSIWYG при серверных шрифтах? Или только XPRINT?
Вот как узнаю, как забивать гвозди, не пользуясь молотком, тогда и расскажу.

>> Разницу между текстом и картинкой не ощущаешь?
> На 100М и гигабитных сетях - не очень.
А я замечаю. И вижу, как дико тормозят фильмы и просмотрщики картинок, хотя менее картиночные приложения работают почти так же.

> За то, что это сообщество ломает то, что хорошо спроектировано и уже работает.
Что оно ломает? Старое все остается как было. А вот новое строится так, как удобно для десктопа, а не для старого.

> Неужели? Не он ли в ноябре прошлого года обновлялся?
http://en.wikipedia.org/wiki/Xprint - там есть слово deprecated. Это я придумал? Идем на домашнюю страничку:
http://xprint.mozdev.org/
Там latest news ажно от 2005. Закопать?

> Вот как узнаю, как забивать гвозди, не пользуясь молотком, тогда и расскажу.
Т.е. так и запишем - в иксовой архитектуре (как ее знает и любит gaa) невозможно обеспечить WYSIWYG без расширения, которое мало кем поддерживается и которое реально сдохло.

А еще там в вики ссылка на коммит, убирающий xprint из сервера xorg ваще. Это называется "обновлялся"?

> А вот новое строится так, как удобно для десктопа, а не для старого.
И это "новое" я ругаю. Что не так?

>> Неужели? Не он ли в ноябре прошлого года обновлялся?
> http://en.wikipedia.org/wiki/Xprint - там есть слово deprecated. Это я придумал?
Надо там [citation needed] выставить.

>> Идем на домашнюю страничку: http://xprint.mozdev.org/ Там latest news ажно от 2005. Закопать?
И шо? Вот последний раз Си стандартизировали в 99 году. Он от этого тоже сдох?

>> Вот как узнаю, как забивать гвозди, не пользуясь молотком, тогда и расскажу.
> Т.е. так и запишем - в иксовой архитектуре невозможно обеспечить WYSIWYG без расширения, которое мало кем поддерживается и которое реально сдохло.
Феерично!

> А еще там в вики ссылка на коммит, убирающий xprint из сервера xorg ваще. Это называется "обновлялся"?

Видел. Стал гуглить "зачем убрали xprint, ироды?". Нагуглил, что его перенесли в плагин, и потому убрали из основной ветки.

>> Неужели? Не он ли в ноябре прошлого года обновлялся?
Цитата из дебиановского changelog-а для пакета xprint. С ноябрём я действительно промазал:

[ Drew Parsons ]
* Patch 95_xprint_disable_dbus disables dbus in Xprint by providing
dummy config functions. Taken from upstream commit
2a3d1421e0cc18822ae8f478fcc272e16a9e9340, with removal of
CONFIG_LIB from configure.ac shifted to 94_xprint_XSERVER_LIBS.
Closes: #472180.
* Enable the xprint DDX, and build the xprint and xprint-common packages.

-- Julien Cristau <jcristau@debian.org> Sun, 18 May 2008 13:36:11 +0200

> И это "новое" я ругаю. Что не так?
Ничего, кроме того, что это новое востребовано. Оно - мейнстрим. Вы же исходите из требований середины 80х, приоритет которых на сегодня копеечный (и Вы ничего с этим сделать не сможете).

> И шо? Вот последний раз Си стандартизировали в 99 году. Он от этого тоже сдох?
Это, извините, унылый троллинг - сравнивать стандарт и реализацию. gcc коммитится постоянно. Реализация на той страничке обновилась в 2005 году, а в мейллисте ноябрь 2006 (показательный диалог "разработчик жив?" - "жив, но не тут").

> Феерично!
О чем и речь. WYSIWYG-а в иксах "с правильной архитектурой" нет.

http://cgit.freedesktop.org/xorg/xprint/

The (deprecated) Xprint server.

Так что можно прямо это вставлять на место citation needed.

Если почитать log, там только ленивый мейнтенанс на уровне "абы компилилось и как-то запускалось".

>> И это "новое" я ругаю. Что не так?
> Ничего, кроме того, что это новое востребовано. Оно - мейнстрим.
Сейчас опять бросимся выяснять, что такое мейнстрим и снова получим, что мейнстрим в понимании svu --- это поделки от мигеля и ко. Знаем, проходили не один раз.

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

>> И шо? Вот последний раз Си стандартизировали в 99 году. Он от этого тоже сдох?
> Это, извините, унылый троллинг - сравнивать стандарт и реализацию. gcc коммитится постоянно. Реализация на той страничке обновилась в 2005 году, а в мейллисте ноябрь 2006 (показательный диалог "разработчик жив?" - "жив, но не тут").
А сравнивать нерабочий проект с редко обновляемым --- это, как я понимаю, полезный и занимательный троллинг?

>> Феерично!
> О чем и речь. WYSIWYG-а в иксах "с правильной архитектурой" нет.
С визивугом проблема одна: интерпретатор постскрипта (в т.ч. в принтере или в cups-овом фильтре) должен получить в точности тот же шрифт, что и был у x-сервера. Всё. Как этот шрифт будет получен: от xprint или же как-то иначе вбит в таблицу соответствия --- не важно.

По всем законам жанра сейчас должен последовать наезд на postscript с заявками, что он устарел, громоздок и гномом не поддерживается. [Попкорн я уже купил.]

> Сейчас опять бросимся выяснять, что такое мейнстрим и снова получим, что мейнстрим в понимании svu --- это поделки от мигеля и ко. Знаем, проходили не один раз.
Не нравится Гном - посмотрите на КДЕ. Они тоже мейнстрим. У Вас есть альтернативное виденье того, что сегодня мейнстрим в пользовательских интерфейсах юникса?

> А сравнивать нерабочий проект с редко обновляемым --- это, как я понимаю, полезный и занимательный троллинг?
В мире опенсорца проект, обновляемый раз в 3 года - мертвый проект. Особенно в том, что касается десктопа. Это не троллинг, это факт из жизни. Живой проект = развивающийся проект. Мне стыдно Вам об этом рассказывать.

Короче, с учетом обоснования слова deprecated - Вы наконец согласились признать xprint RIP - или будете выкапывать его дальше?

> должен получить в точности тот же шрифт, что и был ИСПОЛЬЗОВАН ДЛЯ РЕНДЕРИНГА
fixed (большими буквами). Но это не суть. Так вот - в случае серверных шрифтов Вам придется гнать шрифты на клиент для печати. Что в случае многообразия форматов шрифтов - очень кривое решение, и жрет трафик очень сильно.

На постскрипт наезжать не буду - глупо ругать то, на чем стоит вся печать в юниксе. Попкорн верните на базу;)

> Не нравится Гном - посмотрите на КДЕ. Они тоже мейнстрим. У Вас есть альтернативное виденье того, что сегодня мейнстрим в пользовательских интерфейсах юникса?
Требую определения сущности "мейнстрим в пользовательских интерфейсах".

> Живой проект = развивающийся проект.
Исходя из этого определения, yacc --- живой проект?

> Короче, с учетом обоснования слова deprecated - Вы наконец согласились признать xprint RIP - или будете выкапывать его дальше?
Ладно, выкапывать не буду. Но официальный некролог хотелось бы прочитать.

>> должен получить в точности тот же шрифт, что и был ИСПОЛЬЗОВАН ДЛЯ РЕНДЕРИНГА
> fixed (большими буквами). Но это не суть.
Да, так будет правильнее. А уж где происходит рендеринг --- в данном случае не важно.

> Так вот - в случае серверных шрифтов Вам придется гнать шрифты на клиент для печати.
Что чаще делается: печать чего-либо или отображение окошек на экране? Очевидно, второе.

> Что в случае многообразия форматов шрифтов - очень кривое решение, и жрет трафик очень сильно.
Не менее кривое, чем обучать клиент работать со всеми типами шрифтов. Более того, зачем гнать через клиент, если теоретически (не увидел в купсе такую фичу) можно гнать сразу на принтер?

> Попкорн верните на базу;)
Не берут :(

> Требую определения сущности "мейнстрим в пользовательских интерфейсах".
Очень просто. Интерфейс по умолчанию в дистрибутивах. С учетом размера пользовательской базы каждого. Согласен на экспертную оценку, не обязательны точные данные. Дистрибутивы - это точка встречи пожеланий пользователей с тем, что готова предложить и маркетировать опенсорцевая коммюнити.

> Исходя из этого определения, yacc --- живой проект?
Не знаю. Где почитать commit log?

> Ладно, выкапывать не буду. Но официальный некролог хотелось бы прочитать.
Если будет не лениво - запрошу в мейллисте xorg.

> Что чаще делается: печать чего-либо или отображение окошек на экране? Очевидно, второе.
Безусловно. Просто этим мини-тредом я хотел показать, что в случае требования WYSIWYG серверное решение крайне проблематично, в отсутствие xprint или аналога.

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

> Не берут :(
Расскажите им про рендеринг на сервере - может, не выдержат и возьмут!

>> Требую определения сущности "мейнстрим в пользовательских интерфейсах".
> Очень просто. Интерфейс по умолчанию в дистрибутивах. С учетом размера пользовательской базы каждого.
Отлично, получаем что глобально мейнстрим -- MIcrosoft(r) Windows(tm), а юниксный мейнтстрим --- это гном или кеды (мне даже не важно, у кого сколько пользователей). С таким определением мейнстрима всякие споры не стоят ничего.

>> Исходя из этого определения, yacc --- живой проект?
> Не знаю. Где почитать commit log?
Стал искать и нашёл, что в byacc даже в этом году что-то переписывали. Весьма удивлён.
Но определение мне всё равно не нравится. Предлагаю конкурс: найти нужную программу, которую не обновляли года 3 :)
От себя могу указать fickle и taccle, которые с 2005 года не обновляются, но при этом работают и не жужжат.

>> Что чаще делается: печать чего-либо или отображение окошек на экране? Очевидно, второе.
> Безусловно. Просто этим мини-тредом я хотел показать, что в случае требования WYSIWYG серверное решение крайне проблематично, в отсутствие xprint или аналога.
Ничуть не проблематичнее клиентского.

>> Не менее кривое, чем обучать клиент работать со всеми типами шрифтов.
> С клиентом-то все просто. Либо он знает конкретный тип шрифта (и тогда его и рисует и печатает), либо нет.

> И, что главное, не надо разрабатывать расширение X11,
В десятый разнапоминаю, что ради xft новое расширение _было_ придумано.

> которое умудрится понимать все возможные типы шрифтов (мы же не хотим гонять невнятные блобы с сервера, правда?).
А зачем нам блобы с сервера? Вот что клиент под названием oo.org пишет в postscript-файл, когда его отправляет вместе со шрифтами на печать, то и отдаст.

>> Не берут :(
> Расскажите им про рендеринг на сервере - может, не выдержат и возьмут!
Я им даже про гтк рассказал --- не берут и всё тут! Безжалостные люди %)

Недоответил:

>> Не менее кривое, чем обучать клиент работать со всеми типами шрифтов.
> С клиентом-то все просто. Либо он знает конкретный тип шрифта (и тогда его и рисует и печатает), либо нет.
Это очень хороший довод _против_ клиентской отрисовки. Для всех, кто не является фанатиком одного тулкита.
И напоминаю, что перегрузка тулкита лишней функциональностью тоже ни к чему хорошему (опять же с точки зрения не-фанатиков) не приведёт.

> С таким определением мейнстрима всякие споры не стоят ничего.
Если Вы оспариваете право мейнстрима иногда зачеркивать старые представления о правильном - тогда да.

> Предлагаю конкурс: найти нужную программу, которую не обновляли года 3 :)
Найдете - обязательно расскажите! Для себя я таких прог не нашел.

> От себя могу указать fickle и taccle, которые с 2005 года не обновляются, но при этом работают и не жужжат.
Они нужные? "Работать и не жужжать" - это одно. А быть живым проектом - это другое. hello world вообще вечно живой, а ведь не единого коммита не было, за отсутствием репозитория. Да, простенький проект с минимумом зависимостей можно заморозить и он долго будет "работать и не жужжать" - но это не означает, что он будет реально живым.

> Ничуть не проблематичнее клиентского.
Только отсутствием лишних противоественных посылок по сети. Модель "иксы как фреймбуфер" архитектурно непротиворечива.

> В десятый разнапоминаю, что ради xft новое расширение _было_ придумано.
Это расширение довольно скромное, по трафику не требовательное. Кстати, расширение хоть и было сделано "под xft", но формально к шрифтам не относится.

> Вот что клиент под названием oo.org пишет в postscript-файл, когда его отправляет вместе со шрифтами на печать, то и отдаст.
Представляете себе объемы пересылок для всего этого щастя? Попробуйте оценить...

> Я им даже про гтк рассказал --- не берут и всё тут! Безжалостные люди %)
Звери! Я б побоялся есть их попкорн...

> Если Вы оспариваете право мейнстрима иногда зачеркивать старые представления о правильном - тогда да.
Да вообще с любым мейнстримом, который определяется рекурсивно, т.е. "причина популярности %s --- в популярности %s".

>> Предлагаю конкурс: найти нужную программу, которую не обновляли года 3 :)
> Найдете - обязательно расскажите! Для себя я таких прог не нашел.
Ну вот я две штуки привёл. Надо в толксах спросить.

>> От себя могу указать fickle и taccle, которые с 2005 года не обновляются, но при этом работают и не жужжат.
> Они нужные? "Работать и не жужжать" - это одно. А быть живым проектом - это другое.
До тех пор, пока в tcl нужны аналоги lex и yacc --- нужные. То есть нужные всегда.

> Да, простенький проект с минимумом зависимостей можно заморозить и он долго будет "работать и не жужжать" - но это не означает, что он будет реально живым.
Я бы согласился, если бы тут стояло слово "развивающийся". Но слово "живой" тут совершенно не к месту.

>> Ничуть не проблематичнее клиентского.
> Только отсутствием лишних противоественных посылок по сети. Модель "иксы как фреймбуфер" архитектурно непротиворечива.
Я утверждаю, что "иксы как фреймбуфер" имеют больший порядок малости, нежели нелокальные приложения.

>> В десятый разнапоминаю, что ради xft новое расширение _было_ придумано.
> Это расширение довольно скромное, по трафику не требовательное.
Утверждение голословное, потому как сравнивать не с чем.

>> Вот что клиент под названием oo.org пишет в postscript-файл, когда его отправляет вместе со шрифтами на печать, то и отдаст.
> Представляете себе объемы пересылок для всего этого щастя? Попробуйте оценить...
= отправленному с клиента на сервер в случае уникальных символов и меньше в случае повторяющихся.

> Но определение мне всё равно не нравится. Предлагаю конкурс: найти нужную программу, которую не обновляли года 3 :)

Вот-с: http://www.linux.org.ru/view-message.jsp?msgid=3415586

Особенно порадовало нижеприведённое :)
>Апплет индикатора раскладок клавиатуры для среды Гном
>Copyright (c) Сергей В. Удальцов 1999-2004

> который определяется рекурсивно
По природе он действительно ... слега рекурсивен, как система с положительной обратной связью. Хорошо, не нравится рекурсия - мейнстрим это то, что наиболее соответствует ожиданиям пользователя от интерфейса, наиболее полно соответствует их самым распространенным задачам (хотя, подумав над этим определением секунд 10, сразу вытаскиваем рекурсию опять:)

> Ну вот я две штуки привёл. Надо в толксах спросить.
Ну вот я о них впервые слышу. Да, спросите.

> Я бы согласился, если бы тут стояло слово "развивающийся". Но слово "живой" тут совершенно не к месту.
Хорошо, для меня развивающийся и живой - синонимы. В том, что касается софта. Работающий софт может быть мертвым. Вот я досовскую игрушку 20-летней давности скачал. Она работает под dosemu. Но мертвая она.

> Я утверждаю, что "иксы как фреймбуфер" имеют больший порядок малости
Фреймбуфер - конечно, немного преувеличение. Разумеется, там же всякие расширения типа gl/xrender/... Но никаких "собственных объектов" на стороне сервера. Только то, что от клиента. Или тут тоже "больший порядок малости"?

> = отправленному с клиента на сервер в случае уникальных символов и меньше в случае повторяющихся.
Посылать постоянно понемногу - это совсем не то же, что послать сразу и много.

Впрочем, о чем мы спорим. Жизнь доказала мою правоту, убив xprint.

Мне тут на #xorg-devel дали ссылочку:
http://people.redhat.com/~otaylor/why-xprint-is-wrong.html

> Хорошо, не нравится рекурсия - мейнстрим это то, что наиболее соответствует ожиданиям пользователя от интерфейса, наиболее полно соответствует их самым распространенным задачам
Мне интересны эти "распространённые задачи пользователей". Есть где-нибудь исследования на темы "что делает пользователь на компьютере"? Разумеется, уровнем гораздо выше, чем "запускает evolution". И даже более высокого уровня, чем "читает e-mail".

>> Я бы согласился, если бы тут стояло слово "развивающийся". Но слово "живой" тут совершенно не к месту.
> Хорошо, для меня развивающийся и живой - синонимы. В том, что касается софта. Работающий софт может быть мертвым. Вот я досовскую игрушку 20-летней давности скачал. Она работает под dosemu. Но мертвая она.
"Живым" логичнее положить "работающий в современном аппаратном и программном окружении". Отсюда получаем: dos мёртв, все программы, имеющие проблемы с юникодом, мертвы и т.д.
Следует отметить так же состояние "подаёт признаки жизни". В частности такими признаками могут быть выходящие релизы. Эти признаки не являются критериями, потому отсутствие их о "смерти" однозначно не говорит. Всё так же, как и с живыми существами.

>> Я утверждаю, что "иксы как фреймбуфер" имеют больший порядок малости
> Фреймбуфер - конечно, немного преувеличение. Разумеется, там же всякие расширения типа gl/xrender/... Но никаких "собственных объектов" на стороне сервера. Только то, что от клиента. Или тут тоже "больший порядок малости"?
Порядок малости в том, что единственное место, где я видел живой фреймбуффер: дебиановский инсталлятор. В остальных местах, даже в ущербных девайсах, нормальный x11.

>> = отправленному с клиента на сервер в случае уникальных символов и меньше в случае повторяющихся.
> Посылать постоянно понемногу - это совсем не то же, что послать сразу и много.
Согласен, не то же самое. Но мою оценку количества суммарно переданных данных оно не опровергает.

> Впрочем, о чем мы спорим. Жизнь доказала мою правоту, убив xprint.
Убив конкретную реализацию идеи, а не саму идею. За некролог спасибо, почитаю.

>> Впрочем, о чем мы спорим. Жизнь доказала мою правоту, убив xprint.
> Убив конкретную реализацию идеи, а не саму идею. За некролог спасибо, почитаю.

Прочитал некролог. Убедился, что xprint в его текущем виде действительно не нужен.

Совершенно не понял наезда на "если вам нужно что-то сложное, генерите соответствующий ps". Ну и опять же увидел жонглирование бесконечно малыми.

> Есть где-нибудь исследования на темы "что делает пользователь на компьютере"?
На том уровне, что Вы хотите - наверное, нет. Потому что на этом уровне "что ему дают делать, то он и делает";)

> "Живым" логичнее положить
Наверное, надо разделять ПО и проект (в смысле lifecycle). ПО может быть живым, проект - мертвым.

> Убив конкретную реализацию идеи, а не саму идею.
Что характерно - новой реализации не появилось. Не востребована.

> Потому что на этом уровне "что ему дают делать, то он и делает";)
Мне такое безынтересно. И я яростно против такого к себе, ка юзеру, отношения.

>> "Живым" логичнее положить
> Наверное, надо разделять ПО и проект (в смысле lifecycle). ПО может быть живым, проект - мертвым.
Логично. Только проект может быть ещё и завершённым. Как тот же libjpeg.

>> Убив конкретную реализацию идеи, а не саму идею.
> Что характерно - новой реализации не появилось. Не востребована.
Ещё время не пришло для следующей инкарнации. Эгрегор не готов, если говорить в терминологии астралопитеков.

> Мне такое безынтересно. И я яростно против такого к себе, ка юзеру, отношения.
Кто ж Вам может запретить плевать против ветра?;)

> Только проект может быть ещё и завершённым. Как тот же libjpeg.
Завершенный - тоже мертвый;) Если нет явно выраженной службы поддержки.

> Ещё время не пришло для следующей инкарнации.
Ну конечно, однажды серверные шрифты нагрянут снова, с новой яростью. Тут-то Вы мне покажете кузькину мать!

>> Мне такое безынтересно. И я яростно против такого к себе, ка юзеру, отношения.
> Кто ж Вам может запретить плевать против ветра?;)
А как же "плюй куда дают"?

>> Только проект может быть ещё и завершённым. Как тот же libjpeg.
> Завершенный - тоже мертвый;) Если нет явно выраженной службы поддержки.
А как узнать о том, что поддержки нет, если ошибок в багзилле не висит?

>> Ещё время не пришло для следующей инкарнации.
> Ну конечно, однажды серверные шрифты нагрянут снова, с новой яростью. Тут-то Вы мне покажете кузькину мать!
Слава Серверным Шрифтам! Покайся, еретик и щревты пощадят тебя! :)

> А как же "плюй куда дают"?
Плюйте куда угодно, ветер все снесет в ПРАВИЛЬНУЮ сторону;)

> А как узнать о том, что поддержки нет, если ошибок в багзилле не висит?
Отсутствие явно выраженной багзиллы = отсутствие поддержки;)

>> А как же "плюй куда дают"?
> Плюйте куда угодно, ветер все снесет в ПРАВИЛЬНУЮ сторону;)
Откуда ветер знает, какая сторона правильная? Или... Неужели и землю тоже программисты десктопных сред вращают?

>> А как узнать о том, что поддержки нет, если ошибок в багзилле не висит?
> Отсутствие явно выраженной багзиллы = отсутствие поддержки;)
Допустим, багзилла есть. Что тогда?

> Откуда ветер знает, какая сторона правильная? Или... Неужели и землю тоже программисты десктопных сред вращают?
(скромно, очи долу) не без того...

> Допустим, багзилла есть. Что тогда?
Я не видел багзилл без багов;)

>> Допустим, багзилла есть. Что тогда?
> Я не видел багзилл без багов;)
Без открытых багов с приоритетом defect?

Почему именно defect? Есть всякие enh. Правда, и без дефектов не видел, да.

> Почему именно defect? Есть всякие enh.
Потому что enh может выходить за пределы рамок проекта. Пример: поддержка jpeg2k в libjpeg.

> Правда, и без дефектов не видел, да.
Это же не значит, что их не существует!

> Потому что enh может выходить за пределы рамок проекта.
Когда у проекта есть разработчики, они находят время обозначить такую багу как WONTFIX

> Это же не значит, что их не существует!
Имя, сестра!

>> Потому что enh может выходить за пределы рамок проекта.
> Когда у проекта есть разработчики, они находят время обозначить такую багу как WONTFIX
Логично.

>> Это же не значит, что их не существует!
> Имя, сестра!
Я всего лишь указал на недостаточность доказательства. Наверно, где-то в лесу такие проекты есть.

svu ещё тут?

По поводу бага с xkb:

Я тут открыл ман для setxkbmap и увидел кое-что релевантное:

If you have an Xserver and a client shell running on different computers and XKB configuration files on those machines are different you can get
problems specifying a keyboard map by model, layout, options names. This is because setxkbcomp converts these names to names of XKB configura‐
tion files according to files that are on the client side computer, then it sends the file names to the server where the xkbcomp has to compose
a complete keyboard map using files which the server has. Thus if the sets of files differ significantly the names that the setxkbmap generates
can be unacceptable on the server side. You can solve this problem by running the xkbcomp on the client side too. With the -print option
setxkbmap just prints the file names in an appropriate format to its stdout and this output can be piped directly to the xkbcomp input. For
example, the command

setxkbmap us -print | xkbcomp - $DISPLAY

makes both steps run on the same (client) machine and loads a keyboard map into the server.


Хотелось бы узнать мнение эксперта по переключалкам по этому вопросу.

> Хотелось бы узнать мнение эксперта по переключалкам по этому вопросу.

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

В результате того баг-репорта libxklavier как раз стал использовать локальный xkbcomp. Но это не есть совершенное решение этой проблемы. Дело в том, что клиентский xkbcomp шлет на сервер бинарный формат, аналогичный .xkm файлам. А там хреновый формат - он (нецензурное вырезано) некоторые вещи режет.

См.
http://bugs.freedesktop.org/show_bug.cgi?id=4927
http://bugs.freedesktop.org/show_bug.cgi?id=15540

и там от них еще кой-какие баги зависят.

Да, и соббсно баг-репорт этим не закрывается - мы все равно используем на клиентской стороне libxkbfile, который формально должен быть внутренней библиотекой, не должен использоваться приложениями. Все от того, что RMVLO не специфицирован в XKB.

> Да, и соббсно баг-репорт этим не закрывается - мы все равно используем на клиентской стороне libxkbfile, который формально должен быть внутренней библиотекой, не должен использоваться приложениями. Все от того, что RMVLO не специфицирован в XKB.

Ясно. В очередной раз спасибо за разъяснение.

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

Гы-гы-гы! Сами же рассказывали, что в 90% сервер==клиент, так что трафик не расходуется.

А если принтер-сервер!=клиент и принт-сервер!=сервер, как это обычно бывает даже в маленьких конторах, тогда тем более гонять придется.

> мы же не хотим гонять невнятные блобы с сервера, правда?

А почему не хотим? Может тогда и на диске шрифты хранить в невнятных блобах не хотим, а?

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