ну какой дизай к чёрту ? народ фигнёй мается. Единственная система где правильный дизайн - человек, ну почему эти тупоголовые пытаются приучить человека к искусственному уродству. Пилять задрали стекольщики.

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

> В свое время он учавствовал в
Епта, на LOR-e новости когда-нть без ошибок будут?

Может, я не понял, но автор предлагает что-то вроде микроядерной архитектуры?

> ну какой дизай к чёрту ? народ фигнёй мается. Единственная система где правильный дизайн - человек, ну почему эти тупоголовые пытаются приучить человека к искусственному уродству. Пилять задрали стекольщики.

гы, иди читай файл сначала, он там про технический аспект булькает - где какой код размещать.

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

2Antichrist:
развей свою мысль про то, что такое хаки в биологическом организме.
мне правда интересно.
``Zee''

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

Короче самое идеальное - писать свою граф. систему. Правда не всякий такое сможет в одиночку.

> Может, я не понял, но автор предлагает что-то вроде микроядерной архитектуры?

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

> в пользу динамических библиотек

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

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

Картина маслом "LORовцы учат Гослинга дизайну языков программирования", цикл "Хмурое утро сисадмина", галлерея герцога с "Бофорсом", северное крыло.

;)

Ты зря понёс про религиозный бред (где ты его там нашёл?) и мессагу удалил. Этот бред основан на расшифровке генома человека. Гугл в руки, если интересно. Теория Дарвина рухнула после этого исследования. Нет
никакой последовательной эволюции и никогда не было. Вот такие грустные факты.

> кем доказано? ;) На кафедре билогии МГУ пока говорят обратное. ;) Они отстали от жизни? ;)))

А что смешного? Можно подумать, что МГУ выпускает учёных ;)) Манагеров
среднего звена - это да ;)

Хотя нет, бывают в жизни приятные исключения:
http://www.mtu-net.ru/periodic-sys/textld.htm
Автор - выпускник МГУ ;))

2annonymous (*) (22.08.2004 15:14:51): Автор - выпускник МГУ ;))

На помойку его писульку. Он пишет : "Мутация, как правило, приводит к смерти или уродству."

Если бы человек не мутировал то человечество бы так и не справилось с постоянно мутирующим вирусом гриппа. Этот выпускник просто позор МГУ.

Статья немного сумбурно написана. Вернее, почти тезисно, поэтому многие пункты непонятны...

>Автор предлагает полностью отказаться от клиент-серверной модели (утверждая, что при желании ее можно надстроить уровнем выше) в пользу динамических библиотек, а также ограничить функции базовой оконной либы (т.е. того что он предлагает взамен иксов) исключительно отработкой окон в плане отрисовки в соответствии с Z-order и отсечением.

На локальных машинах, наверное, можно было бы обойтись и без X-протокола. Для этого совсем необязательно выбрасивыть иксы. Присто убрать протокольный слой из общения клиента с сервером на локальной машине. И для этого клиентов переписыватьне надо. Надо, *наверное*, сделать локальную версию xlib, которая не в протокол пидарасит, а напрямую рисует. Можно ли это сделать? какие проблемы при этом возникают? Об этом я еще не думал. Просто изрек первое, что приходит в голову...

> Если бы человек не мутировал то человечество бы так и не справилось с постоянно мутирующим вирусом гриппа.

А я-то не мог понять, откуда на ЛОРе развелось столько мутантов!
А оказывается, виной всему вирус гриппа ;)

В иксах самое ценное это именно X-протокол. Xlib - страшна и вторична.

>В иксах самое ценное это именно X-протокол. Xlib - страшна и вторична.

xlib - прежде всего *стандартна*! К тому же xlib осуществляет много полезных вещей. Например, необходимое кэширование, которое, не было бы ее, пришлось бы тебе самому делать.

Нет, ты все-таки умудрился понять меня, как тебе этого самому захотелось. А где я написал, что надо отказаться от X-протокола? А?

Кстати, а объясни логично, зафиг тебе X-протокол на локальной машине? Не, ну правда? Зачем?

и хочется, и колется, и мамка не велит...

> На локальных машинах, наверное, можно было бы обойтись и без X-протокола. Для этого совсем необязательно выбрасивыть иксы.

1) А это как?

2) А не лучше ли тогда пользовать, скажем, DirectFB?

затем.

> Кстати, а объясни логично, зафиг тебе X-протокол на локальной машине? Не, ну правда? Зачем?

$ ssh -X -f some.server mathematica

Полохому танцору клиент-серверная архитектура мешает...

Только одно не ясно: почему ж таки Photon не тормозит?

> Только одно не ясно: почему ж таки Photon не тормозит?

Потому что его на линух не портировали еще? =)

Кстати, а с каких пор иксы тормозят, собственно? Достаточно поставить какой-нибудь wmi или там ion чтоб убедиться в обратном.

Those who don't understand Microsoft Windows are doomed to reinvent it, poorly.

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

Да нет никаких проблем. Только зачем? Все равно потребуется IPC для разруливания отрисовки разными потоками. Ты не замечал, что все многопоточные программы чем-то напоминают архитектуру клиент-сервер?

Теперь вопрос. Если все равно нужен IPC, почему бы его не сделать через сокеты? На локальной машине - UNIX domain, удаленно - можно по TCP. Вопрос на засыпку: Как называется то, что получилось?

>Кстати, а с каких пор иксы тормозят, собственно? Достаточно поставить какой-нибудь wmi или там ion чтоб убедиться в обратном.

В этом, кстати, нет сомнений. Видел в мэйлинг-листе на XFree86.org были люди, которые непосредственно учавствовали в разработке самого X-протокола. Они довольно убедительно показывали, что X быстрый. Но вот реализация... подхрамывает, по их мнению. Предложили сравнить с коммерческими иксами... Однако на их зов пришел человек, у которого на одной и той же машине стоял коммерческий X-сервер и XFree86. Он утверждал, что видимых различий в скорости не усмотрел.

Вообще ситуация смешная. Каждый показывает пальцем на другого, обвиняя в тормозах... gtk+ обвиняет иксы, иксы обвиняют ядро, ядро иксы, иксы кричит, что это pango медленно рисует... Короче пердоломешка :)... Но так вот и живем. Так вот и никак не разберемся - так что же тормозит? :)

А вот драйвер видюхи, IMHO, надо бы в ядро все-таки пихнуть... Впрочем, у этого есть и сторонники, и противники.

> Так вот и никак не разберемся - так что же тормозит? :)

Ну поскольку всяческие флюксы и ионы не тормозят - дело определенно не в иксах или ядре. Но тут вот какая закавырка - полностью gtk2'шный XFCE4 тоже не тормозит! Так что и не GTK... Больше того, я вполне уверен, что если написать WM на "чистом" Qt (без kdelibs), то и оно летать будет =) А тормозят - гном и кде. В свете чего есть подозрение, что это из-за всяких наворотов типа GConf, bonobo, CORBA, DCOP etc

Ну, пример такого хака, меня в своё время поразивший до икоты: лактозный оперон (и все ему подобные фишки). Google в зубы - или любой учебник по биохимии.

Почему генетичесике и эволюционные алгоритмы так любят порождать кривенькие хаки - читать классику (e.g., Mitchell).

Тонко намекаешь, что у Жабки хороший дизайн? Да канделябром надо по чайнику за такой дизайн, блин...

> Там же всё сплошь одни грязные хаки (как и полагается любому результату эволюционной оптимизации).

Но с другой стороны - язык нижнего уровня (А-Г Ц-Т) работает без изменений.

Насчет 'запихать все в динамические библиотеки' --- неоднозначная идея: в Wins каждая программа тащит свою версию DirectX; и это ничего, кроме головной боли не несет...

> В свете чего есть подозрение, что это из-за всяких наворотов типа GConf, bonobo, CORBA, DCOP etc

Совершенно верно.

>В этом, кстати, нет сомнений. Видел в мэйлинг-листе на XFree86.org были люди, которые непосредственно учавствовали в разработке самого X-протокола. Они довольно убедительно показывали, что X быстрый. Но вот реализация... подхрамывает, по их мнению. Предложили сравнить с коммерческими иксами... Однако на их зов пришел человек, у которого на одной и той же машине стоял коммерческий X-сервер и XFree86. Он утверждал, что видимых различий в скорости не усмотрел.

А может у него коммерческие X кривые были. Или еще что-нибудь кривое. На моей машинке, что с Accelerated X Summit Platinum (demo), что с SNAP (free, only vesa 2.0) gnome летает как twm на Xfree. Товарищи, пишущие эти сервера утверждают, что это из-за аппаратной поддержки 2D операций и сглаживания шрифтов.

призрак GDI...

> Надо, *наверное*, сделать локальную версию xlib, которая не в протокол пидарасит, а напрямую рисует.

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

Это ты DSelect спутал. Наоборот пропадает переключение контекста app -> xserver -> app. Я полностью согласен тут с Гослингом. Будет гораздо быстрей если все локальные программы будут пользовать direct rendering. В этой модели главное правильно решить проблемы с security (через легкий видео драйвер в ядре) и с вводом (это на первом этапе можно делать через сервер).

И как правильно указал Zubok, X вполне может эволюционировать в эту сторону.

Хотя не все так просто. Ведь рисовальные запросы практически всегда асинхронны. Т.е. переключение контекста на xserver достаточно делать только после всей отрисовки.

Пожалуй эволюция X по Паккарду и Геттису вполне реальная дорога. Они убирают xlib и добавили render для сглаженной графики. Все логично.

А у тебя только одно app?

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

Замечание справедливое. Но с другой стороны, не все же одновременно лезут на перерисовку? Как это прокомментируешь?

P.S. Кстати, я на решении этом не настаиваю. Это так. . в голову пришло. Я упоминал, что совсем не думал над ним. :)

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

>> Надо, *наверное*, сделать локальную версию xlib, которая не в протокол пидарасит, а напрямую рисует. Можно ли это сделать? какие проблемы при этом возникают? Об этом я еще не думал. Просто изрек первое, что приходит в голову... > Да нет никаких проблем. Только зачем? Все равно потребуется IPC для разруливания отрисовки разными потоками. Ты не замечал, что все многопоточные программы чем-то напоминают архитектуру клиент-сервер? > Теперь вопрос. Если все равно нужен IPC, почему бы его не сделать через сокеты? На локальной машине - UNIX domain, удаленно - можно по TCP. Вопрос на засыпку: Как называется то, что получилось?

Автор утверждает что современное железо способно само обрабатывать мультитредные запросы: > And an important feature of most accelerators is that they have facilities to efficiently handle multithreaded access. It has become a standard part of a computer’s architecture, alongside integer arithmetic, floating point arithmetic, and networking.

Вот что мне у него не совсем понятно/не совсем понравилось - так это следующее. На нижнем уровне работаем с клип-листами и прочей базовостью. Следующий уровень -- библиотека рендеринга которая имеет прямой доступ к железу (opengl,xlib,ps,...). Выходит, каждая библиотека рендеринга должна иметь свой "минидрайвер" для каждой разновидности видеокарт? C opengl и сейчас так, с xlib(почти) - тоже. Но все равно некрасиво. Производитель видеокарты будет делать десять драйверов под все распространенные rendering library?

Про грязные хаки: поинтересуйтесь как регулируется численность мужчин и женщин в популяции у нас и у обезьян.

> На моей машинке, что с Accelerated X Summit Platinum (demo), что с SNAP (free, only vesa 2.0) gnome летает как twm на Xfree.

На какие коммерческие X сервера для x86 посоветуете посмотреть?
И есть где-нибудь их сравнение?

>Автор утверждает что современное железо способно само обрабатывать мультитредные запросы: > And an important feature of most accelerators is that they have facilities to efficiently handle multithreaded access. It has become a standard part of a computer’s architecture, alongside integer arithmetic, floating point arithmetic, and networking.

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

>Производитель видеокарты будет делать десять драйверов под все распространенные rendering library?

Да, затрахаются. Даешь стандарт унифицированных драйверов для всех ОС! (о какую шнягу придумал - надо будет кому-нибудь присоветовать :))))

mount /dev/brain

> Это ты DSelect спутал. Наоборот пропадает переключение контекста app -> xserver -> app.

Зато будет куча переключений app1/graph_thread <-> app2/graph_thread, не говоря уже о app1/draw_thread <-> app1/working_thread#N

> Но с другой стороны, не все же одновременно лезут на перерисовку?

Как раз _все_ будут лезть, даже те, которые fully obscured (а иначе им должен кто-то сказать, когда именно и что именно перерисовать, т.е. опять возвращаемся к клиент-серверной модели).

> Кстати, я на решении этом не настаиваю. Это так. . в голову пришло.

Зачем повторять чужие ошибки?

>На какие коммерческие X сервера для x86 посоветуете посмотреть?

На Summit (xig.com)? на SNAP(http://scitechsoft.com/)

>И есть где-нибудь их сравнение?

на сайтах есть хорошее сравнение ;)

У меня Radeon 7200 --- и то, и другое когда надо отлично пахало --- весьма шустро.

Summit работает только на старых картах (Voodoo,Radeon<=9200,etc). Надо компилировать его модуль для ядра, который на 2.6.7 перестал собираться.

SNAP работает почти на всем, что умеет 3D ускорять. У меня была их LGPL версия, которая умеет только 2D через Vesa 2.0. Ставится как драйвер для Xfree от 4.0.2 до 4.3.0, более свежие не поддерживает. В ядре использует стандартный agpgart.