> Ясен красен, V86 - нереальный режим!

А это как IOPL поставишь. Если ты про cli.

>cli >halt

Ничего не будет, это запрещено, оно вывалится с окошком илегал оператион(не синее).

если хочешь повесить win9[58] юзай: cli jmp short -2

Будет глухо, как в танке!

> У меня на довольно старой машинке (Athlon 900, 256 Mb) OO Writer
> 1.1.0 грузится 15 секунд (в первый раз, не из кэша!).

Похоже на истину. У меня на Celeron 800/512 - 17сек.

> MS Word 2000 под NT4 - в 2 раза быстрее. Из автозагрузки он
> уьран. Теперь приведи свои результаты.

Не могу - негде. Разьве что в vmware... Но это не очень сравнимо.

>> Без файловой системы ОС не ОС.

> 1) При чем тут ФС и драйвер IDE?

При том, что самой FS надо где-то жить физически. :-)

> 2) ФС прекрасно себе живет в userspace.

Это, в данном случае, к делу не относится.

>> Убойный аргумент. Из-за косяка в драйвере IDE может упасть ядро, поэтому выкинуть его нах из ядра, пускай в юзерспэйсе живет.

> Правильно! Только там им и место.

Кто бы спорил, что в теории микроядро имеет массу преимуществ. Но в реале есть x86, на котором переключение задач стоит слишком дорого (по мнению Linus'а). Поэтому linux не будет микроядром, пока на рынке преобладает x86.

Эх, уважаемый DSelect. Вот я сдержался - в этот тред не влез - а Вас куда-то все-таки понесло...:) Ну все же знают, что Вы любите микроядра больше, чем Танненбаум:).

>> Без файловой системы ОС не ОС.

> Драйвер IDE != файловая система.

все разжевывать надо, никакого образного мышления... ;-) Выше разжевал.

> И где место драйверам, если не в ядре? (говорим про монолитное ядро, каковым является linux).
> Заодно хотелось бы услышать упомянутые аргументы.

Я про них пока не знаю, это была мимолетная прикидка. Что да, может потребоваться. Например, заорать в колонки "Я ПАДАЮ !!!" :-)
На мониторе то же самое можно и в тексте написать, в конце концов... Ну, это лирика.

> Про сложность: reiserfs посложнее графики будет. Ну его нах из ядра?

Надо еще один фактор учитывать - необходимость для работоспособности. Поддержка ФС, это не поддержка 2D/3D.

> Еще раз: я хотел _принципиальную_ разницу между звуком и графикой.
> "Более сложная реализация" -- не катит за качественное отличие.

Как раз катит. Это, кстати, один из вопросов, которые микроядро должно решить. Чем ниже уровень, тем должно быть проще решение.
Но, вообще, звук и графика - это вещи где-то одного уровня с точки зрения логики.

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

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

Народ, основная идеология линукс в распределении памяти укладывается в элементарную формулировку -- "free memory is wasted memory". Вся свободная память со временем распределяется под дисковые буферы для ускорения работы системы. Поставьте хоть 4G и со временем вы обнаружите, что вся память занята. Это сделано специально и это правильно. Т.о. все ваши ранее приобретенные навыки по определению загрузки системы по количеству свободной памяти, приобретенные в DOS/Windows/где-то еще идут лесом...

Народ, не скатываемся до мыльной оперы "Linux vs. The Rest". "Виндузятники", "линуксятники", "красноглазые" и т.д. и т.п. Из пубертатного периода еще не все вышли, что ли? Речь шла про то, что линукс (то, что пользователи имеют в виду, говоря "линукс") ожирел. Вы о чем спорите? Вы не хотите, чтобы ваша любимая система стала легче и быстрее, сохранив или даже улучшив свою функциональность? Пусть она сейчас вас устраивает. Но почему вы не хотите, чтобы она стала ЛУЧШЕ? Никто из вас не разу не думал нечто типа "А вот было бы здорово, если...", имея в виду и скоростные характеристики в т.ч.? Если вам не нужна скорость, зачем вы покупаете новые компьютеры или обновляете старые? В чем причина этого, если скорость старых вас полностью устраивает и они не поломаны? А пока все, что я вижу -- спор ради спора...

>Та шо ви такое гаварите :-) cli halt

И что будет с w9[58]?

Я что-то не понял, это что, доказательство того, что W9X работает в реальном режиме работы процессора, что ли?

>>Та шо ви такое гаварите :-) cli halt

>И что будет с w9[58]?



>Я что-то не понял, это что, доказательство того, что W9X работает в реальном режиме работы процессора, что ли?

Да, блин, писал же, ничего не будет, кроме тупого окошка с иллегал оператион!

Используйте:
cli
jmp short -2

Это - суровые будни любого виндузятника (если он не камикадзе, конечно). Соблюдая эти несложные правила, я не хватал на своих компьютерах вирусов уже года 3. А вот знакомые - периодически. Вы, видимо, тоже :)

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

> а иначе бы другие таблички привел. Например то, что выдает команда ps.

В принципе, у него там тоже информация более-менее правильная есть: второй строкой идет.

Задач нет Небуди Лихо! как говориться пока тихо. Появятся задачи, научится OO поддерживать Vb & JS тады и поглядим!

2ooptimum (*) (12.06.2004 17:23:13)
>Я что-то не понял, это что, доказательство того, что W9X работает в реальном режиме работы процессора, что ли?
Да ладно тебе, винда работает в НЕРЕАЛЬНОМ Ж-) режиме (если заметил, я в исходном сообщении указал в86 виртуальный 86-й), но это не ЗАЩИЩЕННЫЙ режим 386 с разделением задач и защиты памяти, стека, карты прерываний etc, в котором работают все *NT, *nix. Ну ашипка в терминологии вышла Ж-).

>> А ниже -- только иксы с их устаревшим ICCCM.

> Сам ты устаревший!

- Ты дурак!

- Сам ты дурак!

(С) Детский сад #17. (Хожу мимо него на работу.)

> Ты его прочитай и аргментированно поясни в каком месте оно устарело.

Приведи мне, pls, читату из ICCCM, где описано, как мне добавить в программу поддержку drag and drop. И как мне определить формат данных, хранящихся в буфере обмена? Предположим, юзер выделяет файл в файловом манагере, говорит ему "копировать", активирует мое окно, говорит "вставить". Что я должен вставить из буфера? С моей точки зрения, там строка текста. С точки зрения юзера -- имя файла, с которым я должен что-то сделать. Как бы мне разрулить это дело с помощью ICCCM?

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

"Выделить", "вставить", "файл", "буфер" - устаревшие и ненужные понятия. Приложения должны обмениваться _командами_, а не данными (пусть даже и структурированными) и делать каждая свое (и только свое) дело. Это и есть _настоящая_ интеграция.

> Но зачем в этом ковыряться, если и так видно, что под гномом на 10 МБайт свободной памяти меньше?

Чтоб понять, сколько памяти пользуют процессы (и какие именно), а сколько -- блочный кеш...

>> Вопрос - какой версии и на каком ядре (версия и самосборное или "из коробки") ? :)

> Ядро было 2.0.16, версию самого дистра не помню за давностью лет...

Ну тогда понятно, почему оно летало :)

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

> Всегда совпадает. Потому что софт в таких случаях делают для себя.

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

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

А вот тут Вы сами себе противоречите. Как они могут быть "похожи на его собственные", если они "Всегда совпадают" ? :)

> Ты, похоже, тоже не знаешь, а иначе бы другие таблички
> привел. Например то, что выдает команда ps

Могу. Но теперь - только в понедельник. Интересует ps -A ? Весь вывод или отдельные части?

> Народ, основная идеология линукс в распределении памяти
> укладывается в элементарную формулировку -- "free memory is
> wasted memory". Вся свободная память со временем
> распределяется под дисковые буферы для ускорения работы
> системы.

Вот именно - СО ВРЕМЕНЕМ. А не сразу после загрузки. Распределение памяти сразу после загрузки позволяет с допустимой точностью судить о жирности запущенных приложений.
С остальным согласен. Результаты я приводил только для того, чтобы опровергнуть ">300Mb", якобы необходимые KDE.

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

Кто ж не хочет? Только вот даром, по щучьему веленью, ничего не бывает. Линукс интенсивно развивают, пытаясь откусить как можно больше пользователей у винды. Потому речь идёт о приоритетах - какое именно вложение труда и средств позволит привлечь максимум пользователей. Экономия памяти и прочих ресурсов? Сомнительно. Компьютеры нынче мощные, а ориентироваться надо на будущее. Конфетки в интерфейсе? ДА! И это доказал Билл. Вот по его пути и пойдём :) И тут вряд ли что-то сделаешь.

>Да, блин, писал же, ничего не будет, кроме тупого окошка с иллегал оператион!

Да я знаю, что ничего не будет. Это ОН спрашивал. Просто я процитировал криво. :)

> Я не буду разводить flame устарел ICCCM или нет, но пЫонеры не могут свои поделки даже в соответствие с ним привести, а что будет, если более строгий стандарт придумать...

Да при чем тут строгость-то? В стандарте нет нужных на сегодняшний день юзеру фичь.

> В сети работаем с NFS, без всяких blah-vfs, FooPart и прочей гадости...

Ага.

man://foo

smb://share/dir/file

И как я это раздавать по NFS стану?

А есть еще более интересный вид интеграции. PDF в окне броузера. Ты писал выше про древний нетшкаф, но он мог отображать pdf только потому что был спец. плагин для него. На каждый тип контента, не понимаемый броузером напрямую, будем спец. плагин писать? Для мозилы, для конкверора, для ... Есть программа-въювер, и пускай она выводит контент в указанном ей окне (и при этом не забудет добавить свое меню к броузеру).

Еще пример: как бы архиватору встроить в меню файл-броузера пункт "Добавить в архив"? И чтобы при выборе такого пункта этот архиватор все выделенные файлы туда засунул?

IMHO, такого рода интеграцию вряд ли удастся сделать на уровне ОС. На уровне Х сервера -- вполне реально, только это уже должен быть не Х. А пока нет графики в ядре, мало найдется желающих делать что-то совсем непохожее на Х. Потому что придется париться с железом (дурдом! юзерспэйсная аппликуха должна извращаться с железом. ms-dos, блин).

2ooptimum

Упс, сорри, случайно и последний пост вместе с кривой кодировкой удалился. :(

Скопируй плиз из удалённых сообщений (внизу кнопка)

>> Про сложность: reiserfs посложнее графики будет. Ну его нах из ядра?

> Надо еще один фактор учитывать - необходимость для работоспособности. Поддержка ФС, это не поддержка 2D/3D.

Ага. Значит, если сложная, но жизненно необходимая, значит пусть будет. А если сложная, и без нее можно обойтись, значит не надо ее. Ок. ReiserFS гораздо сложнее чем ext3. Это достаточная причина, чтобы выкинуть reiser из ядра? ("графика сложнее текста")

Заметь, тот же fbdev, в частности упомянутый Dselect'ом matroxfb_accel, юзает внутри себя 2D акселератор. Понимаешь? Рисовательный код в ядре уже есть, иначе фрэймбуфер не работал бы. Вопрос лишь в том, чтобы поиметь доступ к этому коду снаружи, из user space (через API).

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

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

> А вот тут Вы сами себе противоречите. Как они могут быть "похожи на его собственные", если они "Всегда совпадают" ? :)

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

> Поэтому для него "всегда совпадают" (с его собственными). А для юзера есть выбор из творчества разных программеров: чей взгляд на софт ему ближе.

Вот вот. Со своими взглядами совпадает, а со взглядами тех, для кого это пишется... :)

>> Поэтому для него "всегда совпадают" (с его собственными). А для юзера есть выбор из творчества разных программеров: чей взгляд на софт ему ближе.

> Вот вот. Со своими взглядами совпадает, а со взглядами тех, для кого это пишется... :)

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

>Интересует ps -A ?

Да нет, сам все измерить могу. :) И под линуксом, и под фрей. Я, собственно, пытался сказать, что занятые 300M -- не аргумент по описанынм выше причинам. Не тебе сказать, а кому-то из предыдущих ораторов. :)

Я сам "линуксоид" со стажем, как говорится, но из-за этого не закрываю глаза на те проблемы, которые объективно существуют в линуксе. Я хочу, чтобы линукс становился лучше и удобнее для всех. Тогда он действительно сможет стать операционной системой №1, но сейчас пока еще нет, к сожалению.

>Компьютеры нынче мощные, а ориентироваться надо на будущее

Ты знаешь, в коропоративном секторе "там" еще очень много железа на уровне PII-PIII. И перделки-свистульки им не особо нужны. Собственно, про это речь в оригинальной статье и шла, что этот сектор линукс упускает. А шанс был...

2Demetrio: Спасибо за подсказку. :)

Re:

Я не пользуюсь линуксом знаете почему??? Потому что я привык делать все в графическом режиме. И командные сторки мне тоже почти не нужны. А чем он вам нравиться и о чем тут так базар затянулся я даже и не знаю.Простая операционка и все.Я так же могу и о винде базарить.

> Потому, что ДЛЯ НЕГО она удобнее. Не зависимо от того, почему так. Считаешь, что нет? Ну так и считай СЕБЕ.
>> А для младенца намного удобнее ползать на четвеньках и срать где попало. Ты считаешь что удобнее ходить на ногах, а срать в отхожем месте? Ну так и считай СЕБЕ, а не пытайся учить других. Наоборот, разрабатывай непротирающиеся ползунки и автоматические собиратели говна - самые полезные вещи в мире.
(ledov)Молодец, хорошо сказал :)
Философ таки. Респект.
.
с. ув.,

Я вообщето ни кого не учу.И ТЫ не думай что я сказал что то против линукса просто я высказал свою точку зрения. А выбирать за меня ты не можешь!

>элементарного завершения имени команды по TAB нету

Ну это ты не прав, есть там она (начиная с w2k), включается правкой реестра. Несколько своеобразная (там по ctrl+u/ctrl+d перебор имен вверх-вниз по алфавиту, а не вывод всех вариантов). А вот консоль энтая с точки зрения на нее, как на терминал, это, конечно, абзац полный...

SalieFF

А есть ли продукт по силе похожий к примеру с canopus pro coder 2.0?

> Ага.

> man://foo

> smb://share/dir/file

> И как я это раздавать по NFS стану?

Речь шла о разных реализациях RPC, и несмотря на эти различия NFS скорее работает, чем нет.

> IMHO, такого рода интеграцию вряд ли удастся сделать на уровне ОС.

Я таки еще раз интересуюсь -- RPC уже отменили? На кой ляд изобретать велосипед?

> На уровне Х сервера -- вполне реально, только это уже должен быть не Х

Не надо, пусть он своим делом занимается.

> А пока нет графики в ядре,

Вам хочется получить на свою голову еще один GDI?

> Потому что придется париться с железом

Зачем? Можно париться с fbdev :)

таки про графику в ядре

> Значит, если сложная, но жизненно необходимая, значит пусть будет. А если сложная, и без нее можно обойтись, значит не надо ее. Ок. ReiserFS гораздо сложнее чем ext3.

Она внутри сложней, а в userspace торчит _примерно_ такой же API.

> Рисовательный код в ядре уже есть, иначе фрэймбуфер не работал бы. Вопрос лишь в том, чтобы поиметь доступ к этому коду снаружи, из user space (через API).

Это ж трындец Linux'-у будет. Он и так не слишком-то изящный, а если туда такую гору кода добавить...

>> элементарного завершения имени команды по TAB нету

> Ну это ты не прав, есть там она (начиная с w2k), включается правкой реестра. Несколько своеобразная

Сильно своеобразная. Команды не дополняет (notep не дополнила, notepad запускается), если пробелы есть - заключает в кавычки. Воблин, а я после кавычек дальше таб жму (ишь чего захотел), оно не дополняет. Понял, не дурак, жму стрелку влево - курсор внутри кавычек - ага дополняет.

И это - сделано для работы, а не для отмазки?

Ну и то, что список не выводит - красота. Зато про кавычки знает, типа умный.

> Вам хочется получить на свою голову еще один GDI?

Нет, нам хочется нормальный HAL. И чтоб драйверы писались не для конкретной версии специфичной реализации X-сервера, а для ядра ОС. Если б так и было - у меня б давно уже иксы от FDo стояли.

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

Если бы линух не был монолитным - вопрос бы не стоял вообще. Дрова писались бы под ОС, как у людей, а не под софт (как те же иксы). Можно сколько угодно твердить про то, что "а вот оно работает", и это правда, но может работать лучше. Да, дабы не разжигать флейма сверх необходимого - я здесь веду речь о модульности, а не микроядерности. Есть, конечно, kernel modules... но когда я делаю "emerge ati-drivers" после каждой пересборки ядра, меня по-прежнему мучает вопрос - почему же нормально написанные драйвера от 2K спокойно работают под XP?..

Но. Сейчас мы имеем то, что мы имеем. В данном случае - монолитноядерный линух. И шансов увидеть его переписанным под микроядро - меньше, чем дождаться-таки Hurd'а. Соответственно, чем предаваться бесплодным мечтаниям в духе "а вот если бы оно было модульное", имеет смысл вести речь о реальных вещах. Так вот в этом контексте - аудио- и видеодрайвера _однозначно_ принадлежат к ядру. Я не хочу менять дрова для своего радеона при смене X-сервера! Больше того, я хочу аппаратное ускорение видео для него же в mplayer'е безо всяких иксов. Чего пока не наблюдается. А должно бы.

2int19h (*) (13.06.2004 10:28:55)
>но когда я делаю "emerge ati-drivers" после каждой пересборки ядра, меня по-прежнему мучает вопрос - почему же нормально написанные драйвера от 2K спокойно работают под XP?..
Извини, но проблема с драйверами Nvidia, MG, ATI - это скорее лицензионно-патентная проблема, родной иксовый nv пересобирать не нужно после пересборки ядра, только аппаратной 2d/3d акселерации не будет по вышеуказанной причине. Ну не могут вендоры открыть спецификацию своих железок из-за лицензионных и коммерческих ограничений. И Linux здесь не при чем, не надо передергивать.

> Нет, нам хочется нормальный HAL.

Скорее всего, не будет его в Linux :((

> Извини, но проблема с драйверами Nvidia, MG, ATI - это скорее лицензионно-патентная проблема,

Ничерта. Драйвер под 2.2 не будет работать под 2.4, вообще говоря -- не будет работать под 2.2, собранным с другим .config'-ом. Это *именно* проблема Linux.

> Так вот в этом контексте - аудио- и видеодрайвера _однозначно_ принадлежат к ядру.

Ууу, тогда сказки о "тормознутости" Linux станут былью... А сколько дырок новых появится... А какой memory footprint будет...

> Я не хочу менять дрова для своего радеона при смене X-сервера!

И при обновлении ядра... Мечты, мечты...

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

С 64-мя можно вполне нормально работать на FC2 в X-ах с OpenOffice, Galeon, GNOME. Тормоза заметны, н они не критические, замедлен только старт приложений. Уровень свапа - примерно 40-50 мегабайт. Ядро пересобранное "универсальное" 2.6.6 (т.е. не заточенное конкретно под машинку, а более-менее применимое на достаточно большом диапазоне железа).

>> IMHO, такого рода интеграцию вряд ли удастся сделать на уровне ОС.

> Я таки еще раз интересуюсь -- RPC уже отменили? На кой ляд изобретать велосипед?

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

>> На уровне Х сервера -- вполне реально, только это уже должен быть не Х

> Не надо, пусть он своим делом занимается.

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

>> А пока нет графики в ядре,

> Вам хочется получить на свою голову еще один GDI?

Не вижу связи между драйвером железяки и GDI. Ты ведь и сам знаешь, что драйвер IDE != файловая система. (аналогия понятна?)

>> Потому что придется париться с железом

> Зачем? Можно париться с fbdev :)

Опять 25... Как насчет аппаратной 2D акселерации? В /dev/null ее?

> То есть, програмер - это вообще универсальный специалист.

Именно так. Иначе он не создаст нормальное ПО.

> Может заниматься чем угодно - всегда будет лучшим специалистом :)

Универсальный, как раз, лучшим не может быть по определению. На то
он и универсальный. :-) Лучшее - удел специального.

>> Значит, если сложная, но жизненно необходимая, значит пусть будет. А если сложная, и без нее можно обойтись, значит не надо ее. Ок. ReiserFS гораздо сложнее чем ext3.

> Она внутри сложней, а в userspace торчит _примерно_ такой же API.

Ок. Графика внутри сложней, а в userspace будет торчать _примерно_ такой же API, что и у терминала. Итак: графика сложнее терминала, reiser сложнее ext3. Если сложность графики достаточная причина для невключения ее в ядро, значит сложность рейзера -- достаточная причина для выкидывания его из ядра, так?

>> Рисовательный код в ядре уже есть, иначе фрэймбуфер не работал бы. Вопрос лишь в том, чтобы поиметь доступ к этому коду снаружи, из user space (через API).

> Это ж трындец Linux'-у будет. Он и так не слишком-то изящный, а если туда такую гору кода добавить...

Откуда возьмется гора кода? Его будет даже меньше, чем у терминальной дисциплины линии. Потому что не надо будет парсить esc-последовательности. Да и ioctls там будет на порядок меньше.

> родной иксовый nv пересобирать не нужно после пересборки ядра, только аппаратной 2d/3d акселерации не будет по вышеуказанной причине

Иксовый nv поддерживает аппаратную 2D акселерацию. 3D -- не поддерживает.

> Ну не могут вендоры открыть спецификацию своих железок из-за лицензионных и коммерческих ограничений

В том-то и дело, что спеки на 2D вполне себе открыты. Закрыто только 3D.

> И Linux здесь не при чем

Как раз таки причем. Драйвера должны быть в ядре (если уж ядро у нас монолитное), а никак не в юзерспэйсе. Иначе получаем MS-DOS: каждая прога, желающая графику, тащит с собой дрова для всего железа, которое она знает. Под "каждой" прогой в случае линукс понимается каждый [XYZ] сервер.

>>Вот я то как раз знал, вот поэтому на кой мне нужна эта левая прослойка? Повторяю весь цикл: запуск X, запуск k3b, поиск нужных парамеров, поиск файлов, или просто:
mkisofs -R -j `find -name '...'` | cdrecord -data -?

Чувак,я имел в виду,что нет разницы чем писать,т.к. пишут одни и те же проги.
Надо начать / продолжить сессию - RTFM
Надо записать каталог со всеми вложенными - RTFM
Надо включить поддержку джольет - RTFM
и так далее.
В к3б(да и прочих мордах) это делается на ходу.
И главное то,что она НЕ ОТМЕНЯЕТ использования стандартных,ВАШИХ,методов.

>> Так вот в этом контексте - аудио- и видеодрайвера _однозначно_ принадлежат к ядру.

> Ууу, тогда сказки о "тормознутости" Linux станут былью... А сколько дырок новых появится... А какой memory footprint будет...

Ну вот вставили в ядро дрова для звуковух всяких. И что? Линукс стал из-за этого тормознутее? Появилась куча новых дырок? AFAIK, уязвимости в основном связаны не с драйверами конкретных железяк, а с более глобальными вещами, такими как VM, например.

И откуда возьмется memory footprint? Отрисовка уже _есть_ в ядре. Требуется лишь получить к ней доступ снаружи. Ну добавить еще несколько функций, в частности рисование линии.

И потом, не надо думать, что все драйвера для всех видях будут одновременно в ядре. Будет какой-то один. Если вообще будет. Сейчас если юзеру не надо fb, значит его и нет. Все будет точно так же. Кому не надо графику, не будет вкомпилять в ядро/подгружать модулем графический драйвер.

>> Я не хочу менять дрова для своего радеона при смене X-сервера!

> И при обновлении ядра... Мечты, мечты...

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

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