Господа, все будет хорошо! Всех на ринг вызовем, не переживайте. Дело-то в прынципе...:) Хотел бы я посмотреть на такую системочку. Хотя не уверен, что хотел бы работать - сложноватисто этакую красотышшу сделать эффективной.

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

Не надо забывать, что Photon сам по себе работает поверх Real-Time OS -- QNX. И потом, я не помню, является ли Photon реализацией X-Window сам по себе, как XFree86, или X-подсистема находится где-то сбоку и поверх Photon'а.

>Цитату.

Хм. Твое "сейчас существуют" я понял как "Твои данные устарели, сейчас есть кое-что новое". А ты, по-видимому имел в виду "да, сейчас существуют только 3, но в принципе их может быть больше". Что ж, я не понял твоей мысли. А ты уверен, что ты настолько талантлив, насколько краток? ;) Шучу-шучу. Не бери в голову.

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

Проблема не в том, что я что-то мешаю. Проблема для тебя по-видимому в том, что тут на самом деле замешаны протоколы как прикладного уровня (X-протокол), так и сетевого/транспортного уровней (TCP/IP сотоварищи). И все они стандартизованы и все они -- ПРОТОКОЛЫ1. Странно, что ты не понимаешь очевидных вещей. Либо просто не знаешь. Ладно, давай я тебе дам еще один пример, более приближеный к жизни. Двое людей, находящихся на расстоянии большем, чем распространяется человеческий голос без применения технических средств, могут общаться если:

1) Они говорят на одном языке (протокол прикладного уровня, в нашем случае -- X-протокол) и

2) Они используют совместимые технические средства для передачи голоса на расстояние -- телефоны, радиостанции, что-то еще (протоколы транспортного уровня, в нашем случае -- TCP/IP и компания).

Ты предлагаешь стандарные протоколы из п. 2 заменить чем-то еще, еще не известным. Ok, ты создал нечто новое (новый транспорт) для передачи голосовых сообщений (прикладной протокол), но дал это устройство только человеку, находящемуся в Москве. Вопрос: как передать ему сообщение из Нью-Йорка, если в Нью-Йорке есть только телефоны?

Если ты считаешь, что до сих пор не понят, то изложи, пожалуйста, свои идеи как-нибудь яснее. А то получается, что я тебе все это время объясняю что-то, а ты лишь утверждаешь, что я ничего не понимаю. Холчешь быть понятым -- потрудись объяснить свои идеи более-менее детально.

> Ты предлагаешь стандарные протоколы из п. 2 заменить чем-то еще, еще не известным. Ok, ты создал нечто новое (новый транспорт) для передачи голосовых сообщений (прикладной протокол), но дал это устройство только человеку, находящемуся в Москве

Неверно. Все локальные клиенты имеют "это устройство" в виде /dev/xserver.

> Вопрос: как передать ему сообщение из Нью-Йорка, если в Нью-Йорке есть только телефоны?

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

Отвечу сам себе. :)

>И потом, я не помню, является ли Photon реализацией X-Window сам по себе, как XFree86, или X-подсистема находится где-то сбоку и поверх Photon'а.

Как я и предполагал, Photon -- это не реализация X Window системы, а сам по себе. Если вы хотите использовать X-приложения в Photon, то должны использовать дополнительную прослойку _над_ Photon'ом -- PhinX.

Впрочем, ровно та же схема существует и в Mac OS X. Их Aqua работает поверх графического ядра Quartz [Extreme], а если есть необходимость использовать X, то также используется дополнительный уровень, реализующий функциональность X11. Детали тут: http://www.apple.com/macosx/features/x11/

Итого, в Windows, Mac OS X и QNX, как минимум, если нужна функциональность X, используется что-то еще ПОВЕРХ их собственной графической подсистемы (собственно, та схема, что я предлагал в моих постах выше). И только мы в линуксе и *BSD используем это старое угребище -- XFree/XOrg, которое уже давно пора заменить чем-то более современным.

>Все локальные клиенты имеют "это устройство" в виде /dev/xserver.

Мля, вот непруха-то. Я не имею. Вот не везет, так не везет. Ладно, ты его только что изобрел, дальше что? Как общаются X-cервер с X-клиентами, помимо того, что используется X-протокол? Клиенты открывают устройство и пишут в него? Назад как? Как будут вызываться callback'и? Чем это быстрее Shared Memory? Далее. Для того, чтобы появился /dev/xserver, ты предлагаешь, как я понимаю, написать новый драйвер для ядра. Почему не написать просто такой же ядерный драйвер, но просто для видеокарты, как я предлагал раньше? В чем преимущество X-сервера в видеокарте? Скорость? Простота реализации? В чем "изюминка" идеи? Почему, по-твоему, это еще не реализовано?

> В чем преимущество X-сервера в видеокарте?

Никаких проблем с драйверами.

> Скорость? Простота реализации?

Естественно. Для разработчиков ядра.

> В чем "изюминка" идеи? Почему, по-твоему, это еще не реализовано?

Ты не забыл с чего все начиналось? Отдельные личности предложили перенести значительную часть Х в ядро. Предложение о переносе этой части Х в видеокарту доводит эту идею до логического завершения (полного).

>Отдельные личности предложили перенести значительную часть Х в ядро

Я один из тех отдельных личностей. Я предлагал перенести драйвера в ядро. И до сих пор я не видел внятно изложенных причин почему этого делать нельзя. Драйвера должны быть в ядре. Просто по определению. Если для этого нет технических ограничений.

>> Скорость?

>Естественно

Не смеши меня. Тот же прокси будет все тормозить. Какая вычислительная мощность должна быть на видеокарте, чтобы обогнать мои P4? А оверхед общения X-сервер - ядро - X-клиенты, вместо X-сервер - общая память - X-клиенты? Сколько стоит вызвать функцию ядра по сравнению с обращением к памяти?

>>Простота реализации?

>Для разработчиков ядра.

А для разработчиков железа? Еще один CPU на видеокарту присобачивать и софт под него писать/отлаживать? Вряд ли GPU способен выполнять хоть отдаленно похожее на X-сервер. Решение в силиконе еще сложнее.

И где ответы на вопросы, поставленные постом выше, относительно callback'ов и прочего? В общем, идея-то вряд ли реализуемая даже в принципе.

> Я один из тех отдельных личностей. Я предлагал перенести драйвера в ядро. И до сих пор я не видел внятно изложенных причин почему этого делать нельзя. Драйвера должны быть в ядре. Просто по определению. Если для этого нет технических ограничений.

Аргументы где?

> Не смеши меня. Тот же прокси будет все тормозить.

Угу, особенно работу локальных клиентов, работающих без прокси.

> Какая вычислительная мощность должна быть на видеокарте, чтобы обогнать мои P4?

Действительно, почему так распространены все эти жифорсы и радеоны? Ведь они не могут конкурировать с твоим П4?

> А оверхед общения X-сервер - ядро - X-клиенты, вместо X-сервер - общая память - X-клиенты? Сколько стоит вызвать функцию ядра по сравнению с обращением к памяти?

1) При схеме карта - драйвера в ядре - Х-сервер - Х-клиенты этот оверхед меньше?

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

3) Ничто не мешает видеокарте писать в память, когда нужно.

> А для разработчиков железа? Еще один CPU на видеокарту присобачивать и софт под него писать/отлаживать? Вряд ли GPU способен выполнять хоть отдаленно похожее на X-сервер. Решение в силиконе еще сложнее.

А что это ты за них так беспокоишься? Не хотят открывать спецификации на железки - пусть реализуют х-сервер сами внутре.

> И где ответы на вопросы, поставленные постом выше, относительно callback'ов и прочего? В общем, идея-то вряд ли реализуемая даже в принципе.

Даже не смешно. Хинт: как это происходит сейчас при удаленной работе? callback'и - фишка уровня клиентских либ.

>Аргументы где?

"Просто по определению" -- это был аргумент. Кроме того, в этом случае использование этого драйвера не будет замыкаться только на одну программу, коей сейчас является XFree86. Это в любом случае будет прогресс. Что лучше, DOS, где всякая программа имеет свои собственные дрова, несовместимые почти ни с кем более, или та же Windows, где дрова одни на всех, если мы отбросим все остальные "за" и "против"?

>Угу, особенно работу локальных клиентов, работающих без прокси.

А удаленных? -- Точно такой же аргумент, что привел ты. Каждая палка имеет минимум 2 конца.

>Действительно, почему так распространены все эти жифорсы и радеоны? Ведь они не могут конкурировать с твоим П4?

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

>1) При схеме карта - драйвера в ядре - Х-сервер - Х-клиенты этот оверхед меньше?

Я считаю, что да. Хотя _сейчас_ размышлять времени нет. Можешь, конечно, со мной не соглашаться. Над п. 2 и 3 тоже завтра поразмышляю. Просто так флеймить, не будучи уверенным в своих ответах, не хочется.

>Даже не смешно. Хинт: как это происходит сейчас при удаленной работе? callback'и - фишка уровня клиентских либ.

Т.е. ты утверждаешь, что они не передаются между сервером и клиентами?

Хорошо, до завтра.

P.S.

> > callback'и - фишка уровня клиентских либ.

> Т.е. ты утверждаешь, что они не передаются между сервером и клиентами?

$ zcat /usr/share/doc/xspecs/proto.txt.gz | grep -i callback | wc -l

0

>$ zcat /usr/share/doc/xspecs/proto.txt.gz | grep -i callback | wc -l

:) Теперь то же самое, только с http://www.xfree86.org/current/xlib.html

> :) Теперь то же самое, только с http://www.xfree86.org/current/xlib.html

:) xlib - та самая либа клиентского уровня. К X-server'у отношения не имеет, она с другой стороны.

Кстати, только в голову пришло. А то мы все о графике, да о графике.

>Предложение о переносе этой части Х в видеокарту доводит эту идею до логического завершения (полного)

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

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

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

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

:) Согласись, что вынести видеодрайвера в ядро все же реальнее. И давай, пожалуй, покончим с этой [занятной] дискуссией. :) Ну хватит уже, право слово.

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

Да? Тогда я этим займусь, вы не против? ;)

Кстати а зачем обязательно байткод? Если гуй сделан строго по MVC, то модель может быть хотя бы и на сях. А отображение - на тикле =) Или на перле. Да хоть на POSIX shell (для максимальной портабельности).

> Не надо забывать, что Photon сам по себе работает поверх Real-Time OS -- QNX.

А с каких пор "real-time" стало обозначать "не тормозит"?

Вроде ж наоборот, ограничения, накладываемые на ОС условием real-time, несколько замедляют ее.

>Сильно крива ее идеология, IMHO. Предпочитаю UNIX way: легкореализуемая кооперация простых программ

Дык нам way нужен или чтоб работало?:)

> С 16 смог загрузить иксы и gdm и gnome-greeter выдал промпт. > Там смог в action menu выбрать Reboot computer, минут через 10 > правда :(( Где-то с 32 уже меееедленно сидел с тремя gnome-terminal, > licq, firefox+thunderbird (не верите?). С 64 то же самое было > побыстрей + запущенный gpdf и несколько открытых сайтов в mozilla

а я сначала подумал что 16 32 и 64 это возраст

> Да? Тогда я этим займусь, вы не против? ;)

Нет проблем. Потом на ЛОРе опубликуйте ссылочку на проделанную работу:)

> Кстати а зачем обязательно байткод? Если гуй сделан строго по MVC, то модель может быть хотя бы и на сях. А отображение - на тикле =) Или на перле. Да хоть на POSIX shell (для максимальной портабельности).

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

>А с каких пор "real-time" стало обозначать "не тормозит"? Вроде ж наоборот, ограничения, накладываемые на ОС условием real-time, несколько замедляют ее.

"Тормозит" -- это когда реакция на события замедлены, будь то нажатие на клавишу, чтение с диска и т.д. Linux не гарантирует тебе ничего, крое того, что событие КОГДА-ТО будет обработано, если ничего не случится. RTOS же гарантирует, что это событие будет обработано НЕ ПОЗДНЕЕ, ЧЕМ... Т.е. время реакции ограничено сверху. По-твоему, что менее подвержено "торможению"?

про тормозящую Mozilla

// это кусок /etc/mozilla/prefs.js

pref("font.scale.aa_bitmap.enable", true); pref("font.scale.aa_bitmap.always", false); pref("font.scale.aa_bitmap.min", 6);

За такие defaults надо отрывать ... да все, что только можно.

> RTOS же гарантирует, что это событие будет обработано

Чушь. RTOS не предоставляет гарантий относительно времени отклика супер-программы-Васи-Пупкина.

> RTOS же гарантирует, что это событие будет обработано

Будет обработано КЕМ?

А одно без другог обычно не бывает.
Кстати помоему лучше сделать так:
железка <=> видеодемон <=> микроядро <=> X server <=> X client
<=> graphic program without window

Видеодемон лежит в юзерспейсе. Предоставляет на выходе некоторый стандартный интерфейс, что позволяет ему работать независимо от ядра. Он умеет рисовать базовые примитивы: точки, кружочки, линии + умеет работать с более сложными вещами (отсечения etc) ничего хорошего в этом нет, но иначе наверное будут проблемы с аппаратной 2,3D акселерацией.
X сервер знает о существовании окошек, контекстов событий etc Графику рисует посредством видеодемона.

>Чушь. RTOS не предоставляет гарантий относительно времени отклика супер-программы-Васи-Пупкина.

Как здесь, оказывается, любят слово "чушь". Однако...

Кто писал про "супер-программы-Васи-Пупкина"? Речь шла конкретно о QNX и ее GUI. А также речь шла о том, что время отклика на события шорошо предсказуемо. Ты хоть раз утруждал себя изучением этой системы или вообще основ RTOS, прежде чем писать "чушь"? Почитай хоть одну страничку: http://www.qnx.com/products/rtos/performance.html

>Будет обработано КЕМ?

Системой. Мля.

чукча — не читатель!

> Почитай хоть одну страничку: http://www.qnx.com/products/rtos/performance.html

Ну и что? Да, гарантируется время обработки прерываний, время переключения между потоками, blah-blah, т.е. производительность _самого ядра_.

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

Время отклика ЯДРА. > >Будет обработано КЕМ?

> Системой. Мля.

Отож, что системой. Ядро честно обработает прерывание, разбудит драйвер, он отработает и отдаст результат "заинтересованному" процессу. А как что этот процесс дальше будет делать -- это его сексуальные проблемы, и никаких гарантий отностительно него ОС _не дает_, да и не может дать.

про "собственные" графические системы

Итого, в Windows, Mac OS X и QNX, как минимум, если нужна функциональность X, используется что-то еще ПОВЕРХ их собственной графической подсистемы (собственно, та схема, что я предлагал в моих постах выше).И только мы в линуксе и *BSD используем это старое угребище -- XFree/XOrg, которое уже давно пора заменить чем-то более современным.

Заметим, что только Photon и X11 обладают сетевой прозрачностью, и отправим все остальное в пешее эротическое путешествие.

про чушь

> Как здесь, оказывается, любят слово "чушь"

Просто многие любят ее пороть...

> Почитай хоть одну страничку: http://www.qnx.com/products/rtos/performance.html

Для начала сами почитайте, о чем там идет речь.

>Просто многие любят ее пороть...

Ты знаешь. Это все слова. Одни лишь слова. "Чушь", "пороть"... Попробуй доказать свои высказывания техническим языком. В чем ты увидел проблему?

>Для начала сами почитайте, о чем там идет речь.

С чего ты взял, что я не читал? Читаю буквально первую строку: "With its preemptible microkernel and priority-based preemptive scheduler". Итак, мы видим, что у RTOS имеется "preemptible microkernel". Если ты напряжешься, то вспомнишь, что в линуксовое ядро тоже не так давно были внесены изменения, чтобы сделать его "preemptible". А для чего это было сделано? А для того, чтобы понизить его латентность? А что такое латентность по-простому? Правильно, это "тормознутость". И кто в первую очередь выиграл от снижения латентности линукса? Правильно, десктоп-пользователи. Сколько восторженных криков было по этому поводу повсюду. А вот в QNX все это было изначально. Читаем далее: "RTOS delivers response times that are both fast and highly predictable". Обращаем особое внимание на "highly predictable", а теперь перечитываем то, на что ты написал "чушь".

Практически любое измерение производительности в итоге приводит к оценке либо "пропускной способности" (throughput) системы, либо ее латентности (latency), либо комбинации этих двух. Коллега int19h, говоря о том, что RTOS по дизайну должны быть медленнее, имел в виду именно throughput. Да, "пропускная способность" у RTOS ниже. Но, говоря о "тормознутости", мы имеем в виду латентность системы, которую мы можем измерить на уровне ощущений. Так вот, латентность у RTOS также ниже. Это характерная черта Real-Time компьютинга вообще.

Так что же тогда "чушь"? Может быть то, что у RTOS гарантирует тебе обработку события в течение определенного интервала времени? Ok. Давай посмотрим хоть на то же определение Real-Time, данное в стандарте POSIX 1003.1: "Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time" ( http://www.opengroup.org/branding/prodstds/x98rt.htm ). Слова "bounded response time" тебе о чем говорят? Если слова тебе не говорят ни о чем, то запусти QNX и поработай в ее оболочке, тогда понимание того, "чушь" это или нет, тебе будет дано в ощущениях...

>и никаких гарантий отностительно него ОС _не дает_, да и не может дать.

Это ее ни мало не ипет. Она его прервет, нах, когда надо, и отдаст квант другому приложению. Еще раз, в очень грубом приближении, но близко по смыслу: тормоза -- это когда не матрица считается медленно, а когда ты жмешь Alt-TAB и 2 секунды ждешь когда процесс переключения-прорисовки закончится. Это и есть латентность. В RTOS она гораздо, ГОРАЗДО ниже.

>Заметим, что только Photon и X11 обладают сетевой прозрачностью, и отправим все остальное в пешее эротическое путешествие.

Да ну и что? Ее что, уровень X11 трудно подгрузить, когда надо? Эта сетевая прозрачность, может, и нужна-то в 1% случаев. Ну наде тебе прозрачность, загрузи модуль, реализующий эту функциональность и все. Скажи, ты хоть той же xineram'ой часто пользуешься? А трудно ее подключить, когда надо? Или speedo. Да как 2 байта переслать.

Photon не тормозит, потому что распростронение света в вакууме есть максимально возможная скорость! Если для вас фотоны тормозят, то вы точно ошиблись вселенной ;)

Ну товарищи я даже не знаю что сказать, ИМХО козырь линукса это не легковесность - это открытость и сообщество большей частью умных людей вокруг. Легковесность это утопия - тут правильно заметили "старые машины -> старые дистры". Хотеть последний КДЕ+ОО+Мазила на P-100 и 16-32RAM конечно не вредно - к слову сказать был P-133 & 32 RAM и M$ Windows 98 на нём чувствовал себя очень х..ево.

Касательно вопроса производительности:

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

Машинка такая: Laptop Mitac 7621P 1000Mhz 384RAM(32 расшарено для AGP) 10HDD Gentoo 2004.1 к сведению 2 болванки всего занимает - первая загрузочная, вторая с пакаджами. Через сеть поставил только Licq всё остальное что надо для повседневной работы - музычка видео текстовые редакторы броузеры итд - было на болванках. При этом на болванках ещё много осталось чего мне не надо.

Юзал собранные базовые пакаджи(stage3) с P-III оптимизацией, ядро 2.6.5, ReiserFS

Честно говоря не ожидал от системы той производительности, которую она показывает - специально делал следующий дамми тест: XMMS + MPEG4 c CD привода + Компилится ядро + Всё это дело в КДЕ(версию не помню - базовая из дистра, думаю довольно свежая) При этом сижу в консоли и комфортно себя чувствую.

Не знаю в чем тут дело, то ли в оптимизации под проц, то ли в ядре 2.6.5 то ли в ReiserFS, но всё это РЕАЛЬНО РАБОТАЕТ. При этом я не говорю о красоте и юзабельности КДЕ по сравнению в M$ XP.

Кстати сказать, установить Win98 на мой прямо скажем экзотический :) лаптоп не получаеца вовсе - дров господа китайцы либо не сделали либо куда-то спрятали для M$98 =)) WinXP ничуть не шустрее - к тому же в XP после переустановки(с ноля) каким-то чудом отвалился COM порт(до переустановки всё работало) так что в виндах я могу юзать GPRS только по IRDA и то СТАБИЛЬНО со второго раза коннектит(в линухе и с комом и с ирдой всё впоряде) Не знаю то ли руки кривые, то ли дрова не в том порядке ставил =))))))))))))))

Так чо-то я отвлекся - короче: Всё что надо в 2-х болванках, РАБОТАЕТ, и намного шустрее чем M$ XP, думал вот поставлю Gentoo и буду с работы потихоньку качать пакетики, а поставил и не знаю что качать-то... всё что надо есть... приходится извращаться.

Так что имхо диета нужна федориному горю и прочим RH&RPM-based поделкам, даже не столько диета сколько тюнинг.