про дубы.

> С дуба рухнул :-) Точно :-)

Смотрим, например, сюда:

http://documents.wolfram.com/v5/Built-inFunctions/Notebooks/index.html

и вот сюда:

http://documents.wolfram.com/v5/Tour/MathematicaNotebooks.html

Самое интересное, что эта зараза кроссплатформенная (во всех смыслах) -- front-end'-ом, работающим на виндовой машине, можно рулить с *NIX'-овой и наоборот.

После этого думаем (если, конечно, есть чем и религия позволяет).

> При том, что X-протокол -- это протокол уровня приложений, а не транспортного. Весь трафик, передаваемый по X-протоколу, надо как-то доставлять от X-клиента X-серверу и наоборот.

Еще раз. Причем здесь tcp/ip? Других транспортов не существует?

Винды это операционка для чайников, линукс - нет. Для того чтобы линукс не тормозил его нужно настроить. Причём, замечу, винды настроить, оптимизировать практически нет возможности. В виндах нет возможности поменять менеджер окон, оптимизировать ядро и т.д. Если Вы оптимизируете линукс, он будет работать очень быстро, не в пример виндузу. Короче, если Вы нихера не понимаете в компутерах, Вы чайник, нехер лездь на линукс, а потом орать что там всё плохо, тормозно и убого. pS: когда сгорел комп дома, мне хватало ресурсов роутера (5x86/32ram) для редактирования исходных текстов и прослушивания музыки, причём из-за того что монитор был такой древний что показывал ТОЛЬКО в графическом режиме пришлось ставить Иксы и fluxbox.

> Вот только фреймбуфер - это уж слижком низкоуровневая абстракция, нужны еще и графические примитивы (линии там, кружочки)

... области отсечения, перекрывающиеся окна.

На самом линух для чайников, а виндовс для реальной работы.

>Еще раз. Причем здесь tcp/ip? Других транспортов не существует?

Cуществуют -- Unix-сокеты. Уговорил, стэк работы с Unix-сокетами будем в карточку прошивать?

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

Это OSF/1->True64 и Mac OS X экспериментальные и узкоспециализированные?

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

Вот и я о том же все время говорю. Улучшение техники чаще всего ведет к увеличению безголовости и криворукости "необразованных самонадеянных идиотов".

А жаль...

> Cуществуют -- Unix-сокеты. Уговорил, стэк работы с Unix-сокетами будем в карточку прошивать?

И еще раз. Причем здесь Unix-сокеты? Других транспортов не существует?

Про внутренности OSF/1 я знаю не очень много (конечно, знаю, что на основе Mach). А OSX запихала очень многие сервисы в ядро - в результате это совсем не микроядро.

>Все снится детям, что им НУЖНО к X-ам на удаленной машине по сети подключиться. Да НЕ нужно это вам давно, вспомните, когда вы последний раз дома (а не на предприятии) это делали?

30 минут назад.

> Заклятые друзья sun. Правда, там не X11...

Не надо менять обсуждаемую платформу - мы же про X11 говорим? Кстати, а Вы каких друзей имеете в виду?

> драйвера не должны зависеть от версии X'-сервера и ядра

Кто бы спорил - очень хотелось бы стабильных ABI... Хотя, про ядро - не согласен. Достаточно стабильного API. Ядро проверяет версию модулей - и это правильно - поэтому надо компилить. Лично мне симпатичен подход vmware - они спокойно (и уже давно) комплят модулечки на лету - и никто не плачет (пока очередное ядрышко API не поломает)... Но это вообще уход в сторону...

Вы таки решили нарушить обет молчания в этом треде? ;) Ну ладно...

> А OSX запихала очень многие сервисы в ядро - в результате это совсем не микроядро

Ну у маковцев положение очень специфическое, сами понимаете. Когда и ОС, и железо по сути контролируются одной конторой, тут вопрос о драйверах особо не встает.

> Ядро проверяет версию модулей - и это правильно - поэтому надо компилить.

К сожалению, далеко не все фирмы согласятся открыть (пусть даже и в таком, предложенном вами, неявном виде) исходники для драйверов.

Кстати, а почему "это правильно"? Вы не думаете, что грамотно продуманная архитектура должна поддерживать и ABI обратно совместимым, позволяя подключать на лету бинарные модули?

> Все снится детям, что им НУЖНО к X-ам на удаленной машине по сети
> подключиться. Да НЕ нужно это вам давно, вспомните, когда вы
> последний раз дома (а не на предприятии) это делали?

Дома у меня компьютер для того и есть, чтобы иногда подключиться
через VPN к сети "предприятия".
А уж на "предприятии" мой линукс-писюк это в основном X-терминал
для работы на нескольких девелоперских Solaris и AIX машинах.
Локально на нем работают броузер да Lotus Notes клиент.
Так что графику без мультиплатформенной сетевой поддержки - ф топку !

>И еще раз. Причем здесь Unix-сокеты? Других транспортов не существует?

И еще раз. Сушествуют 3 способа транспортировки данных между X-серверами и X-клиентами: * UNIX domain sockets * TCP domain sockets * Shared Memory Transport Sockets

Какой из этих методов ты предлагаешь встраивать в карточку?

> Вы не думаете, что грамотно продуманная архитектура должна поддерживать и ABI обратно совместимым, позволяя подключать на лету бинарные модули?

В идеале - да. В реальности - нет ничего страшного (и vmware это демонстрирует) в требовании компилить модуль под конкретную сборку ядра. Потому как железное ABI ограничивает возможность оптимизации. А стабильного API, в общем, достаточно.

А почто тогда сантехники за ABI так упорно цепляются в той же яве?

Да я же сказал - стабильный ABI - очень-очень хорошо. Просто в том, что касается модулестроения ИМХО это не так критично, как стабильный API. Это мое ИМВХО.

> И еще раз. Сушествуют 3 способа транспортировки данных между X-серверами и X-клиентами: * UNIX domain sockets * TCP domain sockets * Shared Memory Transport Sockets

Сейчас существуют. А карточек со встроенным X-сервером для PC не существует никаких.

> Какой из этих методов ты предлагаешь встраивать в карточку?

И еще один (последний) раз. Никакой из этих. X-протокол не должен зависеть от используемого транспорта, поэтому можно выбрать любой удобный.

P.S. А почему ты не предлагаешь встроить tcp/ip стек в IDE-контроллер к примеру?

Если говорить о видеокартах (о чем собственно и шла речь) - на данный момент и NVidia, и ATI не хотят открывать исходники драйверов. Так что, при всей практичности данного подхода, он не проходит.

Посмотрите на дрова винмодемов. Там компилится только небольшой кусочек интерфейсного кода - а остальное сугубо бинарное. А уже внутри драйвера они могут поддерживать стабильный ABI как их душеньке угодно...

И вообще - я не _против_ стабильного ABI. Я просто не вижу проблемы в нестабильном ABI при стабильном API.

>Так что графику без мультиплатформенной сетевой поддержки - ф топку !

Ладно. Только эта мультиплатформенная сетевая поддержка должна быть ДОПОЛНИТЕЛЬНОЙ функцией, которую можно отключать. Под той же Windows, так нелюбимой многими религиозными фанатиками, ведь можно запустить X-cервер в случае необходимости. Вот так и тут должно быть, надо -- запускай. Не надо -- "ф топку". А сейчас X-сервера общаются с X-клиентами даже локально через функциональный аналог быстрой-быстрой сети. Именно это и пораждает тот оверхед, который делает X Window медленнее Windows.

> Именно это и пораждает тот оверхед, который делает X Window медленнее Windows.

Чушь.

>И еще один (последний) раз. Никакой из этих. X-протокол не должен зависеть от используемого транспорта, поэтому можно выбрать любой удобный.

А кто сказал, что он зависит? Но этих транспортов всего 3, и я их выше привел. Ты предлагал встроить X-сервер в видеокарту (ну, может не ты, кто вас анонимов знает). Посредством чего, кроме 3 вышеописанных транспортов ты будешь доставлять сообщения от X-клиента этому X-серверу и обратно, не встраивая поддержку ни одного из них в туже саму карту? Для справки: X-протокол находится уровнем ВЫШЕ этих трех.

P.S. А почему ты не предлагаешь встроить tcp/ip стек в IDE-контроллер к примеру?

Потому что я не предлагал встраивать FTP-сервер в тот же самый IDE-контроллер. Если бы я предложил это сделать, а это практически аналог твоего предложения встроить X-сервер в видеокарту, то мне бы также пришлось реализовывать и TCP/IP стек в этом самом контроллере.

>Чушь.

Да что ты? А что именно тогда?

>> И еще раз. Сушествуют 3 способа транспортировки данных между X-серверами и X-клиентами: * UNIX domain sockets * TCP domain sockets * Shared Memory Transport Sockets

>Сейчас существуют

И какие же дополнительные способы существуют сейчас? Можно полюбопытствовать?

Хорошо пофлеймили.

Догоним и перегоним ветку про реестр.

>Если говорить о видеокартах (о чем собственно и шла речь) - на данный момент и NVidia, и ATI не хотят открывать исходники драйверов. Так что, при всей практичности данного подхода, он не проходит.

Да и фиг с ними. Пусть не открывают. Главное, вынести видеодрайвера в ядро и придумать "правильный" интерфейс для общения с этими драйверами. И чтобы X-подсистема работала не со своими собственными дровами, а с ядерными. В этом случае те же NVidia и ATI выпустят пусть и частично закрытые дрова, но они будут совместимы с этим стандартным интерфейсом, который можно будет использовать не только из X, но и из других мест. А в X работать через псевдодрайвер, работающий не с железом напрямую, а с ядерным драйвером, по аналогии с тем, как X работает с fb УЖЕ СЕЙЧАС.

> А кто сказал, что он зависит?

Ты, когда предлагал строить в видеокарту заодно и tcp/ip стек.

> Но этих транспортов всего 3, и я их выше привел.

Существующих сейчас 3.

> Ты предлагал встроить X-сервер в видеокарту (ну, может не ты, кто вас анонимов знает). Посредством чего, кроме 3 вышеописанных транспортов ты будешь доставлять сообщения от X-клиента этому X-серверу и обратно, не встраивая поддержку ни одного из них в туже саму карту?

"посредством" ядра, создавшего специально устройство. Или для того, чтобы прочитать/записать что-нить в /dev/hda нонче требуется винт с поддержкой tcp/ip?

> Для справки: X-протокол находится уровнем ВЫШЕ этих трех.

Наконец то до тебя дошло. И при этом ничуть от них не зависит.

> Да что ты? А что именно тогда?

Что именно чушь? Да весь твой пост. Ярчайшее проявление невежества.

про overhead

> Именно это и пораждает тот оверхед, который делает X Window медленнее Windows.

А почему Photon не тормозит?

> А почему Photon не тормозит?

Эхх... и почему не сделают десктопную ось на куниксе?..

Серьезно не ковырялся, но на беглый взгяд, Photon - это один из лучших GUI-toolkits, который я видел. Я бы даже сказал, из таковых с API на C - просто лучший. И в плане look'n'feel - тоже.

>Что именно чушь? Да весь твой пост. Ярчайшее проявление невежества.

Друг мой, это все слова. Ты можешь сказать что-нибудь по-существу? Студенты тоже, знаешь, могут осудить профессора в невежестве, если он им рассказывает то, чего они не знают и они не знают, что он профессор. Так что детали, нам нужны детали. Put up or shut up.

> > Вот только фреймбуфер - это уж слижком низкоуровневая абстракция, нужны еще и графические примитивы (линии там, кружочки)

> ... области отсечения, перекрывающиеся окна.

5 баллов :-)

> Самое интересное, что эта зараза кроссплатформенная (во всех смыслах) -- front-end'-ом, работающим на виндовой машине, можно рулить с *NIX'-овой и наоборот. После этого думаем (если, конечно, есть чем и религия позволяет).

Это ты про математику? Ню-ню, реализовать сервер-садйовые виджеты при имеющемся и на сервере, и на клиенте коде этого виджета и дурак сумеет. Ты предложи решение, когда на X-сервере НЕТ виджета, который пытается отобразить X-клиент.

> Ты предложи решение, когда на X-сервере НЕТ виджета, который пытается отобразить X-клиент.

... а вот UT умеет закачивать отсутствующие у клиента моды еще с первой версии ;)

Прекрасно! Реализация server-side widgets в виде загружаемого по сети байткода (на ринг вызываются Java & CLI)! С компляцией в нативность на стороне сервера! caching/versioning/security прилагаются... Это же практически диссерт!:)

2svu: это уже тогда не x-window, а .net-window какой-то получается :-)

> ... а вот UT умеет закачивать отсутствующие у клиента моды еще с первой версии ;)

Байткод

мухи — отдельно, котлеты — отдельно!

> .. области отсечения, перекрывающиеся окна.

НЕ НУЖНЫ эти вещи в _низкоуровневой_ библиотеке. Блин, сначала намешаем все до кучи, а потом будем изобретать всякие DirectX'-ы, xv, mga_vid и прочую муть...

>Существующих сейчас 3.

:) Вообще-то, насколько я помню, несколько постов назад некто утверждал, что их больше.

>Наконец то до тебя дошло. И при этом ничуть от них не зависит.

Что значит "до тебя дошло"? Я это давным-давно знаю. А теперь подумай над следующим примером: представь, что кто-то написал реализацию HTTP поверх NetBEUI, а также создал клиента и сервер, поддерживающие эту реализацию. Но есть одно "но" -- никто, кроме этих двоих, не будет понимать это "чудо". Это будет вещь в себе. Вот так и тут, основная ценность X Window, помимо работы с графикой, в том, что это стандартная кроссплатформенная система, позволяющая работать не только локально, но и, что самое главное, удаленно. Создав X-сервер с нестандартным транспортным протоколом, ты сразу же лишаешься возможности использовать его для удаленного доступа. Не говоря уже о таких "мелочах", как создание чего-то более эффективного, чем общение через Shared Memory, раз уж удаленного доступа мы все равно лишились, да и еще легко реализуемого на всех возможных платформах, где предполагается использовать видеокарту со встроенным X-сервером.

> Реализация server-side widgets в виде загружаемого по сети байткода (на ринг вызываются Java & CLI)!

На ринг вызывается librep :)

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

В случае с Mathematica все просто -- поскольку все графические объекты -- это тоже выражения, то можно задать правило, как из уже существующих виджетов склепать новые. Такой же подход, IMHO, применим и к X-серверу.

> На ринг вызывается librep :)

Скрипач не нужен. На ринг вызывается erlang.

> НЕ НУЖНЫ эти вещи в _низкоуровневой_ библиотеке.

Как раз в низкоуровневой библиотеке эти вещи _необходимы_. Без них аппаратное ускорение - не ускорение, а профанация.

> НЕ НУЖНЫ эти вещи в _низкоуровневой_ библиотеке

Блин, как раз отсечение там как нельзя кстати - и именно на уровне базовых примитивов, поскольку отработкой отсечений и перекрытий при рисовании должна заниматься железка - хотя бы потому, что при разрешении 1024x768 круг радиусом 500 пикселов в любом случае должен прорисовывться через алгоритм отсечения.

> :) Вообще-то, насколько я помню, несколько постов назад некто утверждал, что их больше.

Цитату.

> Что значит "до тебя дошло"? Я это давным-давно знаю. А теперь подумай над следующим примером: представь

Значит не дошло. Пока ты не прекратишь мешать протокол и транспорт для него разговаривать смысла нет.

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

А теперь задача: "склепать" виджет типа gecko (тот самый, который ты видишь в мозилле)