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

> Вот это-то меня и напрягло...

Это не особенность git - они все такие (ну кроме bzr, может быть). Design principle :)

> Второе, конечно, может утонуть. Беда в том, что Вы не заметили, как много лет назад утонуло первое - на всем, кроме серверов. Иксы существовали в какой-то коматозной "Cobol mode". Если Вас это устраивало, то гномовцев - нет.

Чего-то я вообще не вижу никакой комы, и соответственно офигенной пользы от ДЕ. Да, иногда полезно получить селекшн через DCOP, но это редко. Да, часто удобно редактировать файлы на фтп, как будто они локальны, но это можно и нужно делать через что-то типа avfs, доступной в командной строке, а не через хххххххх хххххх ххххх ххххххх довески типа gvfs или ее kde-шного аналога. Я вот хочу сделать греп по фтп-шным файлам, или перловый скрипт там запустить -- как у gvfs с этим?

Да и не уверен что юниксы тонули из-за Офигенных Преимуществ Микрософт Виндоуз Над Недоделанными Юниксовыми Десктопами.

>Насколько я знаю рендерилки (CMIIW), размытость шрифта иначе корректно не достичь. Впрочем, могу ошибаться. В любом случае - ответ на Ваш вопрос по идее тот же самый, по которому xft нельзя реализовать на сервере;)

Только растеризация на клиенте дает теплые ламповые размытые шрифты? А я-то наивный думал, что сервер больше клиента знает о конкретных пикселах.

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

// www_linux_org_ru (оба этих сообщения)

Подозреваю, что железа они _намного_ меньше поддерживали, чем винды.

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

> забавный hello world.. :) а теперь сравни с http://docs.kde.org/stable/en/kdenetwork/kppp/appendix-accounting-template.html

Мне наплевать на недостаток функциональности wvdialer+pppstatus (который можно восполнить, имея логи), а вот как благородный дон будет делать обновление ОС, если из-за неполного обновления у нее слетят X-ы, а сеть имеется только через ppp?

Да и кто мешал делать этот accounting как-нибудь совместимо... типичный nih синдром.

> Это не особенность git - они все такие (ну кроме bzr, может быть). Design principle :)

А это правильный принцип?

> А это правильный принцип?

Зависит от критериев оценки. В общем - да, хотя тем, кто вырос на CVS, это кажется диким.

>> А это правильный принцип?
> Зависит от критериев оценки. В общем - да, хотя тем, кто вырос на CVS, это кажется диким.

В лесу найден программист, воспитанный cvs-ом :)

> Чего-то я вообще не вижу никакой комы
Посмотрите на долю юникса на рабочих местах в середине 90х.

> Я вот хочу сделать греп по фтп-шным файлам, или перловый скрипт там запустить -- как у gvfs с этим?
Лихко. Она умеет использовать fuse

> Да и не уверен что юниксы тонули из-за Офигенных Преимуществ Микрософт Виндоуз Над Недоделанными Юниксовыми Десктопами.
По юзабилити преимущество было безусловным.

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

Да я из того же леса. Меня корчит от git-а...

> В лесу найден программист, воспитанный cvs-ом :)

Тысячи их!!!1111

>> А я-то наивный думал, что сервер больше клиента знает о конкретных пикселах.
> А вот интересно - как Вы собираетесь на сервере реализовать штуки типа компиза...
Речь идёт про тот самый компиз, который пользуется серверным расширением xcompose? Знатный промах :)

>> Единственный резон серверного рендеринга - унификация внешнего вида прикладух с разных клиентов.

>А ничего, что получается неслабое дублирование функциональности, причём с неэквивалентными результатами, что мы можем наблюдать на отрисовке шрифтов через xft в gtk, qt и tk.

Кстати, действительно, основная проблема с рендерингом шрифтов в линуксе: сколько их не настраивай, все равно в разных приложениях будут выглядеть по-разному, особенно когда некоторые приложения вообще с собой носят libfreetype/libxft. Толи дело в винде, все приложения рендерят через стандартный API, и все выглядит всегда одинаково. Даже java под виндой уже использует нативный рендеринг, а в линуксе все также по своему...

Я в курсе про расширение. Но я не очень представляю как работать с ним сохраняя серверный рендеринг шрифтов. Это возможно?

http://stsf.sourceforge.net/docs/Xft-STSF.pdf

там неплохо изложен, почему client-side

1. подтверждаю свои подписи в этой ветке

2. http://stsf.sourceforge.net/docs/Xft-STSF.pdf -- спасибо за ссылку.

>> Я вот хочу сделать греп по фтп-шным файлам, или перловый скрипт там запустить -- как у gvfs с этим?

> Лихко. Она умеет использовать fuse

Из коробки??? Если я зайду через изкоробочную гномовскую gvfs на ftp://example.com/, то в какой директории мне из командной строки греповать по ftp://example.com/*

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

> http://stsf.sourceforge.net/docs/Xft-STSF.pdf

Спасибо за слово stsf. Оказывается server-side сглаживание таки существует.

> там неплохо изложен, почему client-side

Там также неплохо изложено, почему client-side не лучшее решение.

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

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

>> Лихко. Она умеет использовать fuse

> Из коробки??? Если я зайду через изкоробочную гномовскую gvfs на ftp://example.com/, то в какой директории мне из командной строки греповать по ftp://example.com/*

Для архивов я монтировал с помощью /usr/lib/gvfs/gvfsd-archive и потом ходил по ~/.gvfs/что-то_там.
Работает кривовато, частенько падает, тормозит, не может смонтировать 2 архива с одинаковыми basename, но номинально имеется.

Оценка коэффициента кривизны рук разработчиков, у которых основная работа идёт через gvfs, а fuse прилеплен сбоку, оставляются читателю как несложное домашнее задание :о)

> Там также неплохо изложено, почему client-side не лучшее решение.
Во-первых, там все больше изложены проблемы с конкретным freetype, самая существенная из которых - невозможность динамически грузить рендеры (что не является фундаментальным свойством client-side и в принципе легко фиксится, если захотят авторы).

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

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

И, в-четвертых, этот документ написан не вчера. Вопрос (не к Вам, а вообще), почему никто не чешется использовать stsf. Может, что-то там не так?

> Оценка коэффициента кривизны рук разработчиков, у которых основная работа идёт через gvfs, а fuse прилеплен сбоку, оставляются читателю как несложное домашнее задание :о)
При выполнении домашнего задания не забудьте учитывать, что является основными приоритами для разработчиков.

> И, в-четвертых, этот документ написан не вчера. Вопрос (не к Вам, а вообще), почему никто не чешется использовать stsf. Может, что-то там не так?
Кстати, вдогонку - может, у freetype c тех пор таки появилась динамическая загрузка? И почему stsf таки сдох, выдав версию 0.4 ажно в 2003г?...

> В-третьих, некоторые из аргументов за client-side они так и не "закрыли". Например необходимость передавать метрики (в условиях немалой толстоты уникодных шрифтов).
Метрики не нужны подавляющему большинству приложений. А те, которым надо знать всё, создают и без того нехилый трафик.

> И, в-четвертых, этот документ написан не вчера. Вопрос (не к Вам, а вообще), почему никто не чешется использовать stsf. Может, что-то там не так?
И ещё вопрос в догонку к этому: почему никто не читает Достоевского? Может с ним что-то не так? :)

> При выполнении домашнего задания не забудьте учитывать, что является основными приоритами для разработчиков.
Шаттвортовский клич "Слизывай с макоси"!? :о)

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

> И ещё вопрос в догонку к этому: почему никто не читает Достоевского?
4.2. Нормальные люди читают Достоевского. Готовы мне показать нормальных людей, юзающих stsf?

Низачот. Правильный ответ - обеспечение в первую очередь работы десктопных приложений.

> Низачот. Правильный ответ - обеспечение в первую очередь работы десктопных приложений.

Нормальная работа с vfs и обеспечение работы десктопных приложений ну никаким боком не конфликтуют.

>> Метрики не нужны подавляющему большинству приложений.
> Метрики нужны всегда - другое дело, что их можно кешировать. Но приложение начинает с того, что грузит их, хотя б чтоб нарисовать меню.
> Да, и обратите внимание - там в пдф указано, что в Х11 нельзя грузить метрики частично, только все.
Как бы там достаточно advantages, чтобы это принять как данность. Может уже скопипастим документ сюда, дабы не перекидываться цитатами?

>> И ещё вопрос в догонку к этому: почему никто не читает Достоевского?
> 4.2. Нормальные люди читают Достоевского. Готовы мне показать нормальных людей, юзающих stsf?
Вижу, что аналогии ниасиливаются. Придётся прямым текстом: популярность того или иного подхода связана только с его популярностью и ни с какими другими качествами однозначно не связано.

> Нормальная работа с vfs и обеспечение работы десктопных приложений ну никаким боком не конфликтуют.
В условиях ограниченных ресурсов приоритеты правят бал.

> Как бы там достаточно advantages, чтобы это принять как данность.
Это пожалуйста. Но утверждение "метрики не нужны" - 4.2

> популярность того или иного подхода связана только с его популярностью и ни с какими другими качествами однозначно не связано.
Однозначно - нет. Косвенно - да.

>> Как бы там достаточно advantages, чтобы это принять как данность.
> Это пожалуйста. Но утверждение "метрики не нужны" - 4.2
Я повторяю, что 99% клиентов использует метрики шрифта на уровне старого механизма иксов. Который большого трафика не создаёт.

>> Нормальная работа с vfs и обеспечение работы десктопных приложений ну никаким боком не конфликтуют.
> В условиях ограниченных ресурсов приоритеты правят бал.
BEGIN сарказм
Правильно, поэтому будем по сто раз переписывать vfs-модули, потому что это приоритетнее, чем написать конечное приложение, которое работает через обычное api файловой системы.
END сарказм

> Я повторяю, что 99% клиентов использует метрики шрифта на уровне старого механизма иксов.
Это уже совсем другое утверждение. Так вот с ростом размера шрифтов загрузка этих метрик дорожает.

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

>> Я повторяю, что 99% клиентов использует метрики шрифта на уровне старого механизма иксов.
> Это уже совсем другое утверждение. Так вот с ростом размера шрифтов загрузка этих метрик дорожает.
С чего бы? Пара чисел ширина-высота от этого перестаёт влезать в int?

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

Обоснования ясны: на старте проекта "гном" fuse не существовало. Другой вопрос в том, почему гномовская vfs не приведена в соответствие с имеющимися технологиями во времена недавнего её переписывания.

> С чего бы? Пара чисел ширина-высота от этого перестаёт влезать в int?
Кол-во таких пар растет с кол-вом глифов в шрифте.

Я как раз и говорю о том моменте, когда начали делать gvfs после траблов с gnome-vfs. Надо поискать

Единственное, что приходит в голову - нежелание связываться с непозиксовыми опциональными (сырыми?) фичами ядра.

>> С чего бы? Пара чисел ширина-высота от этого перестаёт влезать в int?
> Кол-во таких пар растет с кол-вом глифов в шрифте.
С чего б хелловорлду на русском языке были нужны размеры арабских букв? Да, на сервере будет храниться всё, но это пшик, к тому же оптимизируемый ленивой подгрузкой.

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

Incremental rasterization - with the core X protocol, clients may only retrieve the entire set of metrics for a font rather than individual glyph information. With outline fonts this entails rasterizing every single glyph in the font as part of the application initialization. Given that Unicode fonts may potentially contain potentially hundreds of thousands of glyphs this becomes a serious performance burden, especially given that only a fraction of the information will ever actually be used.

Если действительно шрифты требуют ВЫЧИСЛЯТЬ метрики (правда???), то юникод требует измений от старой схемы -- например, надо шрифты хранить вместе с уже вычисленныим метриками.

With a server-side scheme it may be possible to implement incremental rasterization, but each client would then need to incrementally request glyph information requiring a dramatic increase in the number of roundtrips to the X server. With a client side model glyphs may be rasterized incrementally without requiring those extra roundtrips.

А почему бы не передавать файл шрифта целиком? Обычно они, даже юникодные, в размере меньше мега.

Вобщем, проблемы поставил перех Х-ам юникод. А девелоперы решили не решать эти проблемы, а сделать костыль в виде client side model.

> Это уже совсем другое утверждение. Так вот с ростом размера шрифтов загрузка этих метрик дорожает.

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

> И, в-четвертых, этот документ написан не вчера. Вопрос (не к Вам, а вообще), почему никто не чешется использовать stsf. Может, что-то там не так?

Потому, что быд^W основная масса пользователей юзает Х-ы так, что клиент==сервер, и ей все равно. А девелоперы делают как проще -- а проще сваять свой велосипед, чем сделать разумное расширение Х-протокола.

> С чего б хелловорлду на русском языке были нужны размеры арабских букв?
В документе сказано, что частичная загрузка метрик иксами стандартно не поддерживается. Понадобится расширение.

> А почему бы не передавать файл шрифта целиком?
1. Потому что форматов шрифтов слишком много разных. Блобы неконтролируемые и нестандартизованные по сетке гонять?
2. Потому что файлы бывают нехилых размеров. "Меньше мега" - это несерьезно, извините. Потому что даже несколько сот К - это неприемлемо много для запуска приложения.

>> С чего б хелловорлду на русском языке были нужны размеры арабских букв?
> В документе сказано, что частичная загрузка метрик иксами стандартно не поддерживается. Понадобится расширение.
Да. Я напоминаю, что ради xft тоже было изобретено новое расширение.

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

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