Я что-то не понял.
А что в Линуксе драйвера работают не на Ring0?
Если я хоть что-то помню, то вроде в Линухе вроде все драйвера в ядре (или в виде его модулей - что вроде как монопенисуально), и вообще Линух построен по класической схеме: большое монолитное ядро включает в себя все драйверы.
За это еще Столман Линуса ругал.

Это вроде NT имела правильную архитектуру (пока ее не мелкомягкие разрабатывали, а нанятые спецы) микроядро + драйвера на вынос.
Да начиная с 4 версии они тоже драйвера видео засунули в ядро в целях производительности.

По справедливости надо добавить, что вот HURD имеет правильную архитектуру. Да только больно слабо он развивается.

А самая правильная (последовательная) в этом отношение ОС - QNX.
Но она как и винда платная.

Поправьте меня, если что не так.

J О кольцах защиты в ядре и X11

_Видеодрайверы_ для XFree86 работают в Ring3. X Window System - это обычная прикладная программа. Если она упадет, то ядро (т.е. сам Linux) будет работать нормально. В форточках NT 3.5 видеодрайверы также работали в Ring3. Однако мелкомягким нужна была показуха и они перенесли видеодрайверы в Ring0 для NT 4. Столман критиковал ранние немодульные версии Линукса. Сейчас можно собрать как монолитное ядро, так и ядро + модули. (make modules; make modules_install) А "Иксы" никакого отношения к ядру Линукса никогда и не имели. Кроме того, X Window System имеет свойство встроенного дистанционного распределенного запуска графических приложений, а форточки не имеют. Так что потрясающие Quake III тесты - это огромный успех как Линукса, так и "Иксов" и черный день мелкософта - акции более чем на 5% упали!

QQNX photon vs. X Window System

QNX photon конечно вещь хорошая, вот толька два вопроса: 1.Как быть с распределенным удаленным запуском графических приложений в Фотоне? 2.Как быть с виртуальной памятью в QNX. QNX это все-таки real-time, а Linux - time-shared OS.

esli byt' do kontsa chesnym to
eti samye drivera is ring3 dlya hardware accelerated grafic ispolzuyut
ili zhe drm drivera ili Nvidia drivera (kernel modules) a oni rabotayut
uzhe v ring0 kak i kernel

Uman

Народ! Так почему KDE на FreeBSD сильно быстрее работает чем на линуксе? Все таки видимо не совсем правильная архитектура у линукса

может у тебя линух не оптимизироан был, в отличии от фряки?

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

Ха , так конфить нуна. Кстати о оптимизации - довольно много на sle.how-to.ru .

Кстати , недавно гном попробовал ( новый) так ничё - вполне прилично , но чтоб было сильно быстрее - нет. Только немного.

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

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

Сэр, не занимались бы вы безпардонной агитацией, только маленькие
дети смогут вам поверить про быструю скорость работы KDE во
фряхе, и про медленную в линуксе, а потом еще спойте про
крутость хардверного 3D в фряхе, и все побегут ее устонавливать...

Любой дистр линукса с дефолтными настройками и есть тормоз. Во фряхе
наверное softupdates выставили при установке? Ну так кое-что надо сделать
и в линуксе. Хорошо отлаженный линукс работает значительно мягче под KDE.
У него гораздо лучшая "отзывчивость" на команды пользователя. Для ламерей в дистрах
обычно никаких оптимизаций не выставляют, чтоб меньше саппорт тревожили ;)
RPM-ку с KDE неплохо бы пересобрать под свой проц.

Ну, я тоже не верю, что FreeBSD настолько уж быстрее Linux'a, однако:

По умолчанию настройки FS во FreeBSD более консервативные, чем в Linux. Linux подключает диски в asyncronous mode, ч то несколько быстрее softupdates во FreeBSD(и опаснее :))

2McMCC: А 3D во FreeBSD точно такой же, что и в Linuxe - только, как я понял, и там и там набор поддерживаемых плат сильно ограничен... Ищу Voodoo3 задешево! :)))

Смешно сравнивать Matrox G400 с GeForce2.
У меня стартый комп с G400 а новый с GeForce2
Fastest+640x480 на G400 (P3-500) в бенчмарке дает - 60fps
Fastest+640x480 на GeForce2 (K7-1333) вылетает за 220fps
Вопрос где "нормальный" Q3 :)

OT: насколько хорош i815-onboard 3d accel?

Hi, sorry for OT!
Короче, что можете сказать о мощности 3d-акселя в онбоард-карте на i815 (и под виндой, и под линухом)? Вообще, можно ли на такой хоть под чем-то в q3 погонять? Будет ли fps приемлимым (и каким)? А в X - можно ли иметь 3d acceleration на нем?
Спасибо за ответ заранее!

Мне честно говоря смешно читать эту дискуссию (хотя я уж вроде должен был привыкнуть ко всему). Ну да ладно, просто несколько вещей чтоб вернуть дорогих линуксоидов назад на землю:
1) Квейк3 на сколько я в курсе работает только через ОпенЖЛ
2) МС толкает ДиректХ как замену ОпенЖЛ
Было бы интересно взглянуть на тест где одна и таже программа использует ОпенЖЛ и ДиректХ, чтоб выяснить на сколько первый тормознут по сравнению со вторым, чтоб пересчитать сколько бы давал Квейк под Виндовсом.
PS Верить Регистру да еще в тестах, это как низко надо пасть?

IMHO, совершенно некорректное сравнение будет. Приплетать к этим "тестам" еще и различные 3D-API... Вообще, подхватил народ у тестеров железа привычку мерять скорость чего угодно по timedemo в Кармаковских движках, и радуется.. Давайте попросим Джона дописать в Doom3 вывод лога в syslog и запись статистики по фрагам в MySQL. И будем так мерять их производительность. Вот здорово будет 8)

2DigiMind: Дело в том что прежде чем мерять надо понять, что мериешь. Вот я бы хотел бы и узнать на сколько ДиректХ быстрее чем ОпенЖЛ, потому как сравнение в квейке архитектурных особенностей системы, как тут не которые патаются сделать при малейшем отсутствии понятия, отдает профанацией.

Согласен. Я уже ниже писал, что я по поводу таких сравнений думаю. Не совсем понятно, как тут DirectX всплыл :). Q-engines - OpenGL only (ну разве что Valve к Half-life Директ прикрутили). В одной и той же игре можно сделать поддержку обоих API с совершенно различной производительностью (пример - Unreal). И что тогда мерять?
1. Тест надо писать специально заточенный. Для тестирования опрделенных характеристик системы. Максимально идентичный в обоих системах.
2. Кто может внятно сказать, что именно надо протестировать в ОС, чтобы сказать "у нее правильная архитектура"?

Не совсем ты прав товарищ NikS.
Uman ниже правильно написал. драйверов 2.
один в xfree - другой в ядре.
И то что ядро модульное - монопенисуально, как я уже говорил - все модули работают в ring 0 - в пространстве ядра.
Именно поэтому плохи драйвера от Nvidia - они и к ядру привязаны, и к Xfree.
Что-нибудь одно обновилось, и все - они уже не пашут.

Если уж говорить честно, то и XFree и Linux kernel построены по технологиях 30-ти летней давности, когда hardware был далеко не таким разнообразным как сейчас.
Пример хочешь? Попробуй в X сменить количество цветов без перезапуска самих X и всех приклад.
Слабо?
А и photon и Windows это запросто умеют.
Даже разрешение у X меняется на ходу через одно место - все приклады думают, что они всегда в самом большом из возможных разрешений работают.
Брр-ррр.

Не подумай что я за windows агитирую. Я сам под Linux пишу.
Да только под сервер. Там где вся plug-play'ность нафиг не нужна.
А вот под клинта так мало хороших прилад собственно потому, что с Клиентом именно с точки зрения идеологии у Linux'а проблемы.
И Фрюха здесь ничуть не лучше.
Я уверен, если бы QNX стал открытым, то он бы уже через полгода забил Linux по популярности.

Artem.

На первый вопрос - Вроде гораздо лучше, чем у X.
Там вообще извратные вещи возможны.
(Это сейчас они изврат - через пару лет будут совершенно необходимыми)

На второй вопрос - А нужна ли по большому счету виртуальная память?
В смысле swap? Память сейчас не сильно дорогая, как тогда, когда эту концепцию придумывали.
И swap все равно более, чем в 2 раза память не может увеличить. Да и то не на всех прикладах. Иначе - тормоза жуткие.
Его в QNX организовать можно было-бы, если бы не жесткий real-time.
Уж больно тяжело прогнозировать время, когда часть памяти на винте, который и так занят.

А без swap виртуалка в QNX есть.
(в смысле защищенное адресное пространство)

Artem

Вообще-то, swap в QNX есть (6.х). Его только для GCC ввели :) (эх.. где там OpenWatcom..), Правда он (swap) QSSL не поддерживается и специально оговаривается, что девелоперы не должны расчитывать на него при написании софта. Его могут прибить в будущих версиях.

Многоуважаемый Ogr тут как-то писал что DirectX быстрее OpenGL. Не согласен я с этим. Особенно заметна тормознутость DX на медленных машинах типа моей. Тот же HL так тормозит под DX что просто жуть. В то же время просто летает под OGL. Предвижу, что пойдут оправдания типа "Хреновая реализация DX в HL" Только вот почему-то я и в других гамах не заметил "крутости" DX. И что после этого можно говорить про оптимизацию, крутость и т.п. Мелкомягких технологий? Линух конечно не сахар, но если с ним повозиться недельку, потратить время на оптимизацию системы, то Вень просто сосёт. По всем параметрам. Я лично использую форточки только для игр. Как приставку игровую. А Линух - моя рабочая среда. И никакая из выней линух не сможет заменить никогда, как бы того Билли не хотел.

"Тот же HL так тормозит под DX что просто жуть. В то же время просто летает под OGL. Предвижу, что пойдут оправдания типа "Хреновая реализация DX в HL""
Ага, так и есть.
"Только вот почему-то я и в других гамах не заметил "крутости" DX"
А конкретнее? В каких играх и какой крутости.
Что, DX в Unreal'овском движке плох?

2 Artem

У Nvida kernel модули открытые, после смены ядра - достаточно
перекомпилять.

В X-ах можно менять количество цветов
без перезагрузки.
(см Screen/Display/Depth в XF86config)

Ну и насчёт разрешения ты тоже не прав

Всё от того, что с Linux как десктопом ты работал
очевидно маловато

2 anonymous (*) (2002-01-22 15:06:38.0) 1.под перезагрузкой понимается перезагрузка X а не linux 2.naschet razresheniya perekluchatsya to mozhno s ctrl+alt++ no pri umenshenii razresheniya poluchitsya Virtual Screen( v Xfree 4.x) 3. Bez perezapuska X ty ne pomenyaesh kol-vo tsvetov 4.Drivera NVidia ne otkrytye ! Eto uzhe davno FAQ est dva *.c fila - comptibility layer a vse ostalnoe s chem sobstvenno driver i linkuetsya Binary only

2 Artem nafig nilomu etot QNX ne nuzhen otkrytyi on ili net, net za nim togo potentsiala kak u Linux da i moment uzhe ushel

Uman

Ogr
>>Вот я бы хотел бы и узнать на сколько ДиректХ быстрее чем ОпенЖЛ

Огр, тебе в самом деле интересно, или ты стебешься? Дело в том, что
при "правильных" дровах/железе и при прочих равных условиях под
виндами (ДХ есть только оными)ОГЛ _всегда_ быстрее.
Не вдаваясь в подробности:
DX: App->DX libs->Video Driver->Video Card
OGL: App->Ogl Driver->Video Card
Я надеюсь, ты сам видишь, что здесь "лишнее" звено ;) Что
касается "фичности", то, афаик, DX9 и OpenGL 2.0 будут на одном
уровне. Т.е по большому счету - пофигу под что писать, если не
заморачиваться по поводу +/- десяток ФПС...


DigiMind
>>Что, DX в Unreal'овском движке плох?
Угу. Грубо говоря - никакой. ОГЛ рулит, а вообще-то, конечно, в У/УТ
нужно играть в глайде ;)

2 Uman

2 Uman

Насчет ушедшего поезда QNX ты IMHO совсем не прав.
Скорее поезд Линукса начинает тормозиться.
Проблема современного Linux-ядра в том, что оно слишком большое.
И растет вроде в геометрической прогресии. (по объему)
Со фрюхой та же беда.
А проблема в том, что драйвера железа - в ядре.
А железа нового все больше.
И старое тоже никуда не деется.
Очень скоро Linux упреться в невозможность совершенствования.
Это уже происходит.
Для классического ядра необходим один мастер-девелопер, который сводит все патчи в одну кучу, и проверяет их совместимость между собой.
И нагрузка на этого человека все возрастает.
Линус спихнул это дело на Алана, но Алану это тоже надоело.
Дело даже не в том что ему не платят (может и платят - я не в курсе),
а в том, что это выше человеческих сил.
Нам (линуксоидам) _придется_ переходить на микрокернел.
Нету другого пути.
А правильный микрокернел может совмещать открытые и закрытые куски без проблем. И плевать тогда, что nvidia не хочет отдавать свои драйвера в открытом виде.

И путей здесь два - превращать Линкус в микроядро или брать чужой готовый кусок.
И если QSSL откроет свои наработки для народа (переведет его под GPL как это сделали MySQL) - то народ очень быстро прочухает достоинства правильной архитектуры. Все что из линукса можно будет выкрутить (а можно многое) очень быстро прикрутят к QNX-у (сейчас нельзя - GPL запрещает). И все. Прощай, GNU/Linux - здраствуй, GNU/QNX.
Так что надо не кричать, что мы самые крутые, а использовать самые крутые технологии.
Пока еще есть время на трасформацию Linux в микроядро надо этим пользоваться. Это можно сделать. Не обязательно революцией. Можно эволюцией.
Сначала создать необходимый интерфейс взаимодействия: ядро-драйвер и драйвер-драйвер.
Потом запретить добавлять новые драйвера в ядро.
Потом потихоньку вытащить существующие модули наружу.

Artem

Matrox G400 & Quake3 - вполне ничего ;-)

RedHat Linux 7.2, kernel 2.4.17 (dri-4.2.0), XFree86-4.1.0-12,
glibc-2.2.4-20, PII-450, RAM 128Mb, Matrox G400 16Mb (OEM).
При разрешении 640x480 дает примерно 45-55 FPS.
Хочешь - верь, хочешь - нет.

2Artem
Блажен верующий
Na dnyah prines drug zhelezuaku ide drive for LPT port
I zhalovalsya chto drivera est' tolko pod W95 a u nego 98x i w2k
Ya radi interesa (nikogda takogo zverya ne videl reshil postavit' eto chudo pod linux). 1 Minuta na paride.txt 5 minnut na sborku modulei
dlya drivera i vse rabotaet. Potom tozhe takaya zhe istoriya s Xircom
PCMCIA Ethernet-modem card . Dostal staryu kartu iz laptopa s Linux,
zasunul novuyu i poluchau eth0 i ttyS0(pod lyubye variatsii
windows moi priyatel eto ne smog nastroit)
Vopros kto budet pisat' vse eti drivera dlya QNX ?
Ya dopustim kapayus' s driverom dly c&t 65555 dlya Xfree
i nichem menya ne zastavish pisat' driver dlya QNX - mne eto ne interesno
I tak ya dumayu dlya bolshinstva , tak kto budet dekat' vse eti USB2, Firewire,
PcmCia 36-bit ATA etc. dlya QNX ?

Uman

"Не вдаваясь в подробности:
DX: App->DX libs->Video Driver->Video Card
OGL: App->Ogl Driver->Video Card"
А можно немножко подробностей? Если это цепочки вызовов функций, то куда делась Opengl32.dll, которая должна здесь стоять как OGL lib?
И как быть с клиент-серверной архитектурой OGL, которая вносит свои накладные расходы?

"Угу. Грубо говоря - никакой. ОГЛ рулит, а вообще-то, конечно, в У/УТ
нужно играть в глайде ;)"
Не надо тут мертвецов вспоминать :). И давно OGL зарулил D3D в анрыльском моторе? Я как-то прозевал сей знаменательный момент...

P.S.: А вообще, конечно же OGL рулит ;)

>И как быть с клиент-серверной архитектурой OGL, которая вносит свои накладные расходы?
какие такие накладные расходы?
заслать на серверную часть (в память карты) данные и не заботится о том,
как она их сохранит и в каком порядке обработает- отличная идея, и по мере увеличения "интелекта" GPU и колва набортной памяти рулит все сильнее и силнее.
к тому-же, если не ошибаюсь, D3D здорово привязан к C++, в то время как OpenGL есть для любой экзотики
вплоть до http://www.haskell.org/HOpenGL/
+в D3D присутствуют не имеющие к графике отношения приблуды типа формата файлов "X"- на кой ляд?
P.S а серьезные карточки от www.3dlabs.com или ATIшные FireGL D3D не поддерживают- игрушечное API....

>Нам (линуксоидам) _придется_ переходить на микрокернел.
>Нету другого пути.
Что бы поиметь все тормоза этой причудливой архитектуры?
Нахрен.... И QNX нахрен туда же, зачем нужен многозадачный DOS,
который даже сервером никогда не станет, да еще к тому же
на микроядре... Что бы написать "правильный" микрокернел,
нужно много труда, времени и денег, а у QNX Team похоже с этим
туговато, даже если его завтра сделают полностью под GNU, то
вымирание его на этом не остановится, поздно пить баржоми, когда
легкие отпали....
P.S. Одни предлагают для скорости работы KDE фрибзд поставить,
другие, у которых ядро линукса, видите ли, стало из штанов
вылазить - QNX, третьи, у которых OpenGL тормознут по сравнению
с D3D - винды, хотя по моему разумению glide гораздо круче и
шустрее их обоих вместе взятых, ну да ладно, завтра придут четвертые и будут BeOS втюхивать, как самую быструю загружаемую систему в мире, и насколько линуксисты потеряли
в плане мультимедийности, утверждая на полном серьезе, что звук в линуксе не такой как в BeOS, да и шо нет у нас такой феньки
как перетаскивать картинки из одного места в другое, через
клипбоард... Мля...не надоело еще? Ну работайте с тем, что
вам нравится, а то взяли еще манеру, "...вы не подумайте, что я
ххххх защищаю, но работаю то я в линуксе...", если бы эти
сэры работали в линуксе полностью, а не как только с сервером,
то таких бы изречений небыло, так что думайте с кем водиться,
а кого посылать на х.....

>Сначала создать необходимый интерфейс взаимодействия:
>ядро-драйвер и драйвер-драйвер.
>Потом запретить добавлять новые драйвера в ядро.
>Потом потихоньку вытащить существующие модули наружу.

А если еще нахер привязать фонарь, то можно будет и ночью
работать.... Если вам так интересно из "Кировцев" делать
эвалюционирование в самолеты с вертикальным взелетом,
то не проще ли создать свое направление, как это сделано
с Real Time Linux'ом, и назвать его типа MachLinux или каким-нибудь
еще экзотическим именем, хотя такой проект существовал,
а может даже и сейчас существует, что гораздо проще вам будет к
нему присоедениться без изобретания велосипеда заново?
Ну а мы тем временем, не искушенные в таких напастиях,
будем сравнивать скорость Q3 в супер-пупер микрокернельных
XP и монолитноядерном линуксе, делая при этом выводы, как
сосут эти микрокернелы у монолитноядерных....

>... glide гораздо круче и шустрее их обоих вместе взятых,
glide для графических API это типа DOSа для OS- на столько-же круче и в тех-же случаях шустрее
мир праху...

"Что бы поиметь все тормоза этой причудливой архитектуры?
Нахрен.... И QNX нахрен туда же, зачем нужен многозадачный DOS,
который даже сервером никогда не станет, да еще к тому же
на микроядре..."
Где DOS? 8-о.. И чем микроядро для сервера не угодило? Попахивает отсебятиной..
"Что бы написать "правильный" микрокернел, нужно много труда, времени и денег, а у QNX Team похоже с этим туговато"
Гы :). Фирма QSSL занимается разработкой своих микроядерных ОС с 1981 г. И неплохо себя чувствует (тьфу.. тьфу.. тьфу..).
"даже если его завтра сделают полностью под GNU, то
вымирание его на этом не остановится, поздно пить баржоми, когда
легкие отпали...."
Полностью под GNU его никогда не сделают.
Вымирание? Где???
У меня вопрос. Уважаемый вообще в курсе о чем речь?

"к тому-же, если не ошибаюсь, D3D здорово привязан к C++, в то время как OpenGL есть для любой экзотики"
У D3D - COM-интерфейс. В принципе, можно привязать к чему угодно.

"в D3D присутствуют не имеющие к графике отношения приблуды типа формата файлов "X"- на кой ляд?"
Формат файлов для хранения анимации, геометрии etc. Это не графика? И используется он только в D3D Retained mode, который в игрушках не юзают.

DigiMind
>>куда делась Opengl32.dll
Собсно, отмазка насчет "правильности" дров и железа давалась не зря -
в этом случае упомянутая библиотечка (в виндах - ОГЛ 1.0, 1.1)
никогда не используется,а используется ОГЛ драйвер (ОГЛ 1.2-1.3)
видеокарты (который в большинстве случаев можно тупо скопировать в
Opengl32.dll).

>>ATIшные FireGL D3D не поддерживают
Уже поддерживают ;)

>>хотя по моему разумению glide гораздо круче и
шустрее их обоих вместе взятых
Шустрее - это да. Потому как проще. Но вот круче - эт врядли - оно
неразвивается, фич новых добавлять некому, да и незачем, имхо - если
развить глайд "до упора", то получиться еще один ОГЛ, который
работает только на картах покойной 3dfx... ;)

>Гы :). Фирма QSSL занимается разработкой своих микроядерных ОС
>с 1981 г. И неплохо себя чувствует (тьфу.. тьфу.. тьфу..).
Вот пусть и сидит в своей области спецприменения и не лезут туда,
где они явно никогда не будут...

>Полностью под GNU его никогда не сделают.
Вы это тем скажите, кто губенки раскатил до пупка....

>Вымирание? Где???
Именно там, где они пытались вытеснить линукс и даже об
этом протрубив, где только можно было...

>У меня вопрос. Уважаемый вообще в курсе о чем речь?
Да! Об Quake3 под Linux, который работает быстрее, чем в WinXP,
и каким хреном подвязался к ним QNX...

P.S. В окончании этой темы...
Что же касается, не возможностью повесить QNX драйверами,
расскажите это малым деткам, сам лично под нее делал порт
звукового драйвера с ALSA для AC'97 под i81x, система просто
мерла и не гугукала, и где эта хваленная локализации проблемности
вокруг ядра? Драйвер я конечно не доделал, но и криминального
в нем ничего такого небыло, что бы вешать _ядро_...

>Вот пусть и сидит в своей области спецприменения и не лезут туда,
>где они явно никогда не будут...
Я не знал, что QSSL всерьез толкает QNX на десктоп или сервера.

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

>Да! Об Quake3 под Linux, который работает быстрее, чем в WinXP,
и каким хреном подвязался к ним QNX...
Еще раз извиняюсь. Я думал мы уже на QNX переключились. И каким хреном он подвязался..

>Что же касается, не возможностью повесить QNX драйверами,
>расскажите это малым деткам, сам лично под нее делал порт
>звукового драйвера с ALSA для AC'97 под i81x, система просто
>мерла и не гугукала, и где эта хваленная локализации проблемности
>вокруг ядра? Драйвер я конечно не доделал, но и криминального
>в нем ничего такого небыло, что бы вешать _ядро_...
:))))))))))))

>Формат файлов для хранения анимации, геометрии etc. Это не графика?
формат файлов в драйвере видеокарты? не смешно
>И используется он только в D3D Retained mode, который в игрушках не юзают.
так я и спрашиваю- на кой ляд?

>>ATIшные FireGL D3D не поддерживают
>Уже поддерживают ;)
действительно (2 из 6, если не путаю)
http://www.ati.com/na/pages/products/workstation/workstation_index.html

2Uman

Я имел ввиду именно пререгрузку X.
Те она не требуется.

Насчёт nvida - я же написал _KERNEL_ driver.
X-вые конечно закрыты, кстати не только у nvida,
также у Matrox, все наверно видели Hall библиотеку,
без которой 3D не увидишь.

Короче, внимательно читай сообщения :)

2DigiMind:
>Я не знал, что QSSL всерьез толкает QNX на десктоп или сервера.
Мне вломы искать эти утверждения, но тогда по вашему куда они
его толкают?

>>Что же касается, не возможностью повесить QNX драйверами,
>>расскажите это малым деткам, сам лично под нее делал порт
>>звукового драйвера с ALSA для AC'97 под i81x, система просто
>>мерла и не гугукала, и где эта хваленная локализации
>>проблемности вокруг ядра? Драйвер я конечно не доделал, но и
>>криминального в нем ничего такого небыло, что бы вешать
>_ядро_...
>:))))))))))))
Очень смешно.... Есть API и документация , где явно говорится об
порте ALSA под QNX, есть в конце концов готовый драйвер
от той же ALSA для Linux'a, небольшая переделка под QNX
опираясь на API, много времени не займет, только вот не
работает звуковой драйвер для i81x, вешает систему мертво
и ничего не сделаешь, да я бы тоже посмеялся над убитым временем,
только вот нет этого драйвера под QNX и по сей день, видимо
не один я так облажался, но речь шла не об моей компетентности,
а об той заоблочной крутизны QNX и как драйвера не могут
завесить систему, даже если они кривые, это собственно был
пример тем, кто это тут утверждал выше, т.е, не лично вам...

2 McMCC: Да я понял. Предлагаю похоронить этот тред, потому как уже давно с темы съехали.

2anonymous (*) (2002-01-22 12:02:17.0) aka Artem

> Если уж говорить честно, то и XFree и Linux kernel построены по технологиях 30-ти летней
> давности, когда hardware был далеко не таким разнообразным как сейчас.
Если уж говорить честно, то ложка с вилкой, что ты каждый день пользуешься,
построены по технологиям 1000 летней давности, когда еда была далеко не такой
разнообразной как сейчас.

> Попробуй в X сменить количество цветов без перезапуска самих X и всех приклад.
ЗАЧЕМ?
Вообще, конечно, Иксы много чего не умеют. Например, BSOD показывать.

> А и photon и Windows это запросто умеют.
От бедности и непродуманности базовых технологий.
В Win графику от ОС не оторвать, вот и приходится извращаться.
А X-ы, как-то так сложилось, вполне самодостаточны.

Нужно тебе запустить приблуду ОБЯЗАТЕЛЬНО на 32 bpp, запусти ее в других Иксах
с 32 bpp и переключайся между экранами.

Интересно... Если ядро поддерживает текстовый режим, то почему бы ему не поддерживать графический? Если есть поддержка шрифтов в текстовых режимах, то почему бы не заменить ее на поддержку некоторого ограниченного множества в графических? Ведь есть уже довольно давно стандарты на графические режимы...

NikS (*) (2002-01-21 19:09:55.0)

>_Видеодрайверы_ для XFree86 работают в Ring3. X Window System - это
>обычная прикладная программа. Если она упадет, то ядро (т.е. сам
>Linux) будет работать нормально.
Смотря как упадет, а то может ядро и будет работать,
а аналог синего экрана можно получить в два счета.
Это ИЗВЕСТНЫЙ баг "нвидейных" драйверов, проявляется по
разному на разной технике - при стартовании иксов вместо запуска
оболочки получаешь серый или черный экран, и приходится позорно
ПЕРЕЗАГРУЖАТЬ линукс.
Это происходит примерно от 2 до 4 раз из 10!
С радеоном действительно проблем не было никаких.
Насчет возможностей иксов согласен - их гораздо больше.
По поводу игр - накрылась компания Loki, так что
игр будет меньше(последний SUSE идет с кучей неплохих игр - один
Descent чего стоит ).
Dear ALL, ткните, плз, URL'ом с подробными инструкциями по инсталяции
Q3 и UT, Unreal.

> Интересно... Если ядро поддерживает текстовый режим, то почему бы ему не поддерживать графический?

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

Хорошо, но, к сожелению, текстовый режим все более становится приспособленным для вывода только отладочной инфы... А, например, с Unicode могут быть проблемы, которые можно решить в таком "псевдотекстовом" режиме.

Не думаю, что Линух без видеокарты будет удобен на десктопе :)

1 Было бы интересно запустить два квейка под виндами и два под одними X-ами 2 Было бы интересно запустить две Х и в каждой по квейку (n -нное кол-во X-ов и в каждой по кваке)

сравнить и посмотреть что будет

Есть те кто может и кого не ломает?