ALSA вошла в ядро Linux 2.5.5pre1

Наконец-то, имхо ALSA гораздо побогаче возможностями. НАдеюсь, конечно, что и OSS останется - хотя бы для совместимости. :))

Кто-нибудь реально пользуется 2.5.(более-менее последними)? Чем компилировали?

Это есть хорошая новость :)) Было бы совсем хорошо если бы ALSA включили бы в ядро 2.4.*
Только я еще не разбирался используют ли ALSA возможности 5.1-звука

Когда-то угораздило купить меня CS4281 карточку. Протр$#@ся я с этой ALSA дня 3. Бросил. Подождал следующий релиз, где явно говорилось, что, мол, да такая карточка поддерживается. Ага. Щас. Та же фигня (в смысле секс, не приносящий удовлетворения). Ну, плюнул на это дело, поставил OSS. Хотя, конечно, странно, когда драйвера стоят дороже железа (в данном случае по крайней мере), зато с пол-пинка работают.

Может что-то с тех пор изменилось у ALSA в лучшую сторону, но спасибо, уже не надо...

1. alsa эмулирует OSS. т.e. вы ничего не теряете
2. afaik только alsa держит аппаратный миди на SBLive
3. Конечно-же для людей недалеких огромным недостатком является
необходимость чтения при установке длинного readme и описанное
там огромное количество параметров для тюнинга карты. Для них
совершенно не имеет значения возможность управлять поведением
драйвера отдельно для каждого приложения, поддержка full duplex
и одновременной работы с драйвером сразу нескольких приложений.

Хорошая новость. давно пользуюсь альзой и никаких претензий.
хотелось бы только поболше информации о карточках и их работе с альзой.
хочется аппаратного микшера, а кто кроме sblive! держит его, даже не в курсе. опять таки, как 5.1 включить и использовать тоже непонятно.

Практического толка в слиянии имхо уже немного.
альза и так выходит параллельно с ядром и прекрасно на нем компилится.
по крайней мере, с точки зрения пользователя это выглядит совершенно прозрачно:
apt-get install kernel24
apt-get install alsa24
и все стоит и работает.
для продвинутого пользователя еще проще
apt-get source kernel24
rpm --ba kernel24.spec
rpm -i alsa24
rpm -i kernel24
куда теснее то?
это в альтовских дистрах, но, думаю, в друних дистрах не хуже.

2surfer:

Насколько я понял из твоего постинга поддержка микширования звуковых
потоков будет работать на уровне драйвера, впрочем это есть и в
драйверах с oss.creative.com. Меня больше интересует если там
независимая регулировка громкости каждого из звуковых потоков.
Просто в oss такая поддержка, насколько я понимаю, может быть
реализована как откровенный хак. Связи между двумя открытиями
/dev/dsp и /dev/mixer нельзя отследить. Надеюсь в alsa с этим
нет проблем.

p.s. Сейчас вот смотрю доки но пока не нашел еще.

У меня и в 2.4 ALSA сидит, так что тут никаких новшеств я чета не заметил. Дистр. ALT Linux Junior

Народ! Я очень уважаю и ядро, и OSS, и ALSA. Но зачем же все одну кучу?!

Было бы здорово не вносить модули в ядро, а выносить из них - в отдельные проекты. Чтобы человек, сливая ядро - сливал минимальный набор драйверов. А остальное чтобы можно было сливать и добавлять в виде driver.o (конечно, без патченья ядра). Я не маньяк от Mach, но та помойка, которую делает Линус из ядра - подозрительна. Минимальный набор драйверов (или вообще без оных:) и kernel API for modules - вот было бы маленькое и симпатичное ядрышко. И самим же kernel developers and maintainers полегчало бы... Похоже, ядро живет под логунгом "Догоним и перегоним OpenOffice". Неужели никто, кроме меня, не обеспокоен этой тенденцией?

По поводу модулей, в 2.5 вроде собираются сделать некую файловую
систему в имэдже ядра с набором модулей к нему. По поводу разработки,
перед занесением в ядро некоторые драйвера разрабатываются в отдельных
проектах. По поводу внесения в ядро драйверов, а в alsa в том числе
входит kernel-driver (библиотека и программы в ядро не вносятся),
они драйверы и хотят работать в режиме ядра. А разбивать ядро на
разные проект не желательно из-за того, что проекты развалятся
при плохом взаимодействии, по той же причине, что и не работают
бинарные модули от других ядер. При реализации жестких интерфейсов
(необходимых для устранения бинарной несовместимости) затормаживается развитие.

IMHO

>> Когда-то угораздило купить меня CS4281 карточку

Это часом не та, котрая работает как эмуляция I810?

Развитие, говорите, затормаживается? А то, что поддерживать раздутое ядро без _четко_ и достаточно _жестко_ определенных внутренних API не сможет ни Линус, ни Алан, никто другой ("ни бог, ни царь, и ни герой")? Может, и хорошо, чтобы reiserfs был отдельным проектом (хотя, конечно, под него kernel-to-module API менять придется часто и много), alsa, smbfs, ...? Конечно, они могли бы влиять на ядро в смысле улучшения ядерных API (например, если alsa нужен доступ к какой-нибудь спрятанной структуре). Почему такой сложный продукт как vmware обошелся маленькими поправками в ядро - и все, теперь спокойно компилит свои модули при установке и не требует включения их в Линусовое дерево? Почему драйвер моего winmodem справился скомпилиться и незаметно подложить себя в виде модуля? Почему alsa до сих пор справлялась подкладывать себя в ядро в виде модулей? И, я думаю, поддерживать эти API хотя бы в рамках одной серии ядер (т.е. при изменении третьего номера) - было бы просто хорошим тоном не зависимо от моих идей (хотя бы чтобы производители binary only drivers a la nvidia могли спать без кошмаров).

Другое дело, что производители дистрибуций могут по своей воле это пихать в один или множество rpm/deb/tgz...

На самом деле, когда я задумался обо всем этом - я понял, что смелое утверждение Линуса, что linux was not designed - на самом деле _очень_ грустная правда. И грустнее всего то, что Хозяин до сих пор настаивает на своем праве думать про design меньше, чем про development:)

Vmware - комерческий софт, его модуль не включат в офицалбное
ядро именно по этой причине, а на счет одного модуля на все
ядра это не так, когда я ставил vmware в эго поставке как минимум
было модуля 3 и не один мне не подошел а сорцовый не собрался ;)
Пришлось ставить одно из поддерживаемых ядер.
Драйвера nvidia отдельная песня, тоже закрытая libа + отрытый
модуль, не будет включен по той же причине. Сейчас вот только
что система подвисла из-за него, говорил же себе не
переключаться в консоль при работающих иксах.
На счет reiserfs, alsa и других, так надо еще доказать что
ты достаточно стабилен для включения тебя в ядро, поэтому
некоторое время каждое новшество живет вне ядра в виде патча
или отдельного проекта.
Вообщем, ты прав, Линус тянет все до кучи, или способствует
этому, но это потому что если сделать возможным модульность
то из этого ничего хорошего не выйдет. Появится много binary-only
драйверов которые отладить будет непросто и это не улучшит
надежность. Есть еще такое осложнение, когда какая нибудь
контора написала бинарный драйвер и забыла. Вот это и будет
сильно держать интерфейсы, причем при некоторой кривости
драйвера надо будет не трогать некоторые места ядра иначе
драйвер почему-то перестает работать не известно по чему
(он же бинарный). Вот такое у меня понимание этой проблемы.
Так что я думаю на данном этапе развития эта структура ядра
оправдана.
А по поводу высказывания Линуса, так это его просто по
философствовать потянуло, да и похоже надоедать ему начинает
это все (Может бы я ошибаюсь). Я эти слова для себя трактую
следующим образом, а может я все правильно понял:
Нельзя заранее придумать все и потом это реализовать. Можно
реализовать какой-то блок ядра и потом ты или кто-то другой
увидит возможность более простой/эффективной реализации
более удачного интерфейса и др. это и есть развитие. А
Линус себя видит в роли этакого демона Максвелла, который
выбирает из множества возможных/полученных решений наиболее
удачные под действием давления со стороны пользователей
этих решений. Считается, что в среднем у лучших решений
больше пользователей. :)

Ладна, что-то я разошелся....

Нда-ссс, смотришь и понимаешь что действительно - знания сила... Ну у меня на ноутбуке этот чип стоит, ALSA его с полпинка взяла - дело было весной прошлого года. Проблема была только в том что мануал надо было читать внимательно - там hint почти в конце был уже.

Так что зря ты деньжата отдал, имхо...

Вот у меня с этим чипом проблем ну ни разу небыло... Да у меня вообще проблем нет :))) Может, руки кривые? :)))

Насчёт деления ядра на много мелких проектов: это не нужно, потому что приведёт к ухудшению взаимодействия между частями ядра (из-за ухудшения взаимодействия между людьми их пишущими). Вместо этого, имхо, нужно просто разделить один большой kernel-x.y.z.tar.bz2 на несколько маленьких. На кой мне качать, например, драйверы SCSI, если у меня его нет и не будет? Или, например, драйвер фреймбуфферной консоли для amiga, если я работаю на x86?

btw, я тоже уже больше полугода использую ALSA и единственной проблемой с ней было то, что у меня не получилось заставить заработать эмуляцию OSS/Free с devfs.. Может, посоветуете что?

Toster, я использую бинарный драйвер nvidia и у меня тоже постоянно висла система при переключении в консоль из запущеных иксов. Потом прочитал про баг в AMD'шных процессорах при работе с AGP, сделал у себя append "mem=nopentium" и зависоны исчезли. xfree86-4.2.0, kernel 2.4.17, duron800, kt266, tnt2 vanta. Sorry за оффтопик.

   Когда-то  угораздило  купить меня CS4281 карточку. Протр$#@ся я с этой
   ALSA  дня  3.  Бросил.  Подождал следующий релиз, где явно говорилось,
   что,  мол,  да такая карточка поддерживается. Ага. Щас. Та же фигня (в
   смысле  секс,  не  приносящий удовлетворения). Ну, плюнул на это дело,
   поставил  OSS.  Хотя,  конечно,  странно,  когда драйвера стоят дороже
   железа (в данном случае по крайней мере), зато с пол-пинка работают.
Драйвера для СS4281 есть в vanilla ядрах 2.2 и 2.4 - и работают прекрасно.
Не стоило гоняться за alsa и OSS.

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

to Toster :

>Драйвера nvidia отдельная песня, тоже закрытая libа + отрытый
>модуль, не будет включен по той же причине. Сейчас вот только
>что система подвисла из-за него, говорил же себе не
>переключаться в консоль при работающих иксах.

1.0-2313 ? У меня такие-же глюки были пока не переехал на
SuSE Kernel 2.4.16, дрова от nVidia 1.0-2313, XFree 4.2,
Сейчас вроде пока всё тип-топ...

сервер был вломломан через модуль звуковой карты:)))

>сервер был вломломан через модуль звуковой карты:)))
Нет, через закрытый драйвер nvidia, для ускорителя geForce 3, без него сервак не хотел тянуть Quake 3: Arena сервер. Вот не хотел и все! :-)

Спасибо за советы, но я не вдавался в детали:
ядро висло при переключении обратно в X после запуска в консоли
dosemu в графике (попросили). =nopentium не влияет - у меня
AthlonXP, на него вроде эта ошибка не распространяется. Вообщем,
с mem=nopentium все равно подвисло.
NV драйвера последние как и X и ядро.
По поводу перехода на SUSE: не конструктивно, не буду же
я переходить на какую-то другую систему с единственной надеждой,
что здесь все магически заработает. Предпочитаю заниматься
локализацией проблемы. Если уж куда и буду уходить с debian то
на ALT linux :)

2Toster: хм, у меня debian/woody, 2.4.17, XFree86 4.1.10-13, мама A7V266 (KT266), AthlonXP, видюха Asus V7700(Geforce2 GTS)

были глюки с 3D, перед nvidia стоял radeon какой-то, так вот, глюки с 3D вылечились выкидыванием agpgart нахрен... хбз как я его сразу не выкинул когда карточку поменял и ядро пересобирал, такие пироги, btw, его не только в ядро нельзя но и модулем нельзя

так-что проверь на всякий случай :)

PS. dosemu у меня нету и ставить проверять не буду :)

Про vmware я писал "модули". Да, их, вроде, 3.

И со всеми проблемами, вытекающими из модульности, я знаком и хорошо понимаю, к чему призываю. Но альтернатива-то еще хуже. Она называется словом "помойка". Кстати, спасибо за фразу "Вообщем, ты прав". Про binary only драйвера - бояться не надо. Они, во первых, все равно - есть и будут есть. Во-вторых: то, что API для модулей будут жестко отслеживаться и будет вестись их versioning - это только облегчит всем жизнь. Нужно рассказывать историю про старый binary-only драйвер для винмодемов Люцента? Там все было завязано на одно поле в какой-то ppp структуре, который злобный Линус (или кто там еще) поменял (добавил или убрал) посреди серии 2.2. Хорошо, теперь opensource вариант появился... При этом Линус не должен подписываться на неизменность интерфейсов вообще и навеки. Он просто должен будет аккуратно следить за их версиями. И, по возможности, не менять их посреди серии стабильных ядер.

2 anonymous (*) (2002-02-16 22:00:37.0)
У меня без agpgart не поднимется 4x и fastwrites на KT266A

2 svu (*) (2002-02-16 23:23:42.0)

Совместимость в понимании линуса это imho неизменность внешних интерфейсов
ядра (/proc, /dev numbers, sycall numbers) остальное может меняться
в любой момент. Его не заботит, что кто-то привязался к каким-то
интерфейсам, каким-то особенностям реализации. У ядра линукса нет
замороженного экспортируемого интерфейса для модулей...
(Так я залез в дебри, правильность последнего предложения не гарантирую)
Я считаю у разработчика ядра должна быть некоторая свобода,
хотя бы в том, чтобы менять внутренности ядра. :)
Если разделять ядро на отдельные проекты, то возникнет та же проблема
что и у гнома - проблема в сборке и соответствия версий. Нет идеальных
людей - нет идеальных интерфейсов.

Вообщем, давай дадим людям занимающимся этим делом решать, что им
надо. Я думаю если все станет сильно плохо, то линус это увидит, или
ему помогут это сделать.

2svu: Это какой opensource драйвер для lt winmodem ? там опять же тонкая обязка и бинарная либа

toster, по поводу " 2 anonymous (*) (2002-02-16 22:00:37.0) У меня без agpgart не поднимется 4x и fastwrites на KT266A"

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

toster, по поводу " 2 anonymous (*) (2002-02-16 22:00:37.0) У меня без agpgart не поднимется 4x и fastwrites на KT266A"

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

Про winmodem - согласен, погорячился. Но моя мысль от этого не меняется - проблемы с двоичной совместимостью вечны и не зависят от того, "послушается" меня Линус или нет. Проблемы будут до тех пор, пока есть компании, желающие делать binary only drivers (что само по себе неплохо). И nvidia - очень хороший пример. При всем их мощном железе некоторая часть технологий живет и в драйверах, и, я думаю, они никогда их не откроют. Имеют право (даже Алан Кокс, идейный товарищ, про это говорил). То же - про винмодемы, винпринтеры,... А говорить, что Линукс будет поддерживать только хард с доступными спеками - производители харда обидятся сильно очень. Так что - придется-таки Линусу решать эту проблему. А если он не станет этого делать (Хозяин - барин), то в этом месте начнут подставлять костыли IBM/RedHat/... Что лучше - костыли или живые ноги?

Про "дадим людям решать" - конечно, забавно бы я выглядел, пытаясь запретить отцам-основателям делать то, что им хочется. Меня просто интересовало, один ли я в своих параноидальных опасениях. Похоже, один:)

В завершение, предлагаю лозунг: "Хороший интерфейс важнее хорошей реализации". Люди, забывающие про это, обречены на кошмарный maintainance...

>Почему такой сложный продукт как vmware обошелся маленькими
>поправками в ядро

И поехали: 2.0.3 - после ядра 2.4.4 не собиралась.
2.0.4 без исправления на ядра после 2.4.9 не собиралась.

Альса - для такого-то ядра (по-моему 2.4.14) и старше мы выпустили
версию 5.12b (ну не помню я точно цифры - качал месяц назад).

Зашибись, а пока ее не выпустили, мне что, без звука сидеть?
Теперь в ядрышке все будет, мы настроечки какие надо выставим
и геммороя станет меньше.
Еще бы xfs туда как-нить включили бы и все было бы замечательно.

P.S. И не помойка, а компоненты на более свежие меняются и все
хорошее притягивается.

да сколько можно повторять? берите ядра с SGI из cvs

http://oss.sgi.com/projects/xfs/cvs_download.html

в настоящий момент доступна версия ядра 2.5.4-pre1-xfs
что надо заменить в этих инструкциях, для того чтобы качать не 2.4 ветку, а 2.5 догадайтесь сами

---
wtf_

конечно я имел в виду, что доступна версия 2.5.5-pre1-xfs

---
wtf_

SVU что значит ядро-помойка?

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

Так что? У всех ядро 2.5.5-pre1 компилируется и работает?
Или не у кого?

[dick@dick dick]$ uname -a Linux dick.home 2.5.5-pre1-xfs #5 Сбт Фев 16 17:13:53 MSK 2002 i686 unknown

что? не все собирается? ну-ну

--- wtf_

Вот только достижение это жалкое. В той же Windows такие вещи уже давно работают и отлично, надо сказать. И если поет в одной проге, то и в другой будет петь.

А тут никак не могу заставить петь Mplayer. KDE - поет отлично, XMMS - тоже. А MPlayer - молчок. Хоть через OSS, хоть через SDL (ARTs) - пофиг.
Карточка SiS 7012

to Eugeny Balahonov :

>Вот только достижение это жалкое. В той же Windows такие
>вещи уже давно работают и отлично, надо сказать. И если
>поет в одной проге, то и в другой будет петь.

Мы вот тут прикупили Windows XP Professional (для тестирования
нашего софта) и решили поставить на MB QDI + Duron 900 MHz + 512MB
мозгов. Но вот просто вмерзает XP во время инсталляции.

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

Усeк ?

2 anonymous (*) (2002-02-17 04:48:45.0)
Должно быть так:
(18:08:28)[ivan@baltica ivan]$cat /proc/nv/card0
----- Driver Info -----
NVRM Version: NVIDIA NVdriver Kernel Module 1.0.2313 Tue Nov 27 12:01:24 PST 2001
Compiled with: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
------ Card Info ------
Model: GeForce2 GTS/GeForce2 Pro
IRQ: 11
Video BIOS: 02.15.01.13
------ AGP Info -------
AGP status: Enabled
AGP Driver: AGPGART
Bridge: Generic Via
SBA: Supported [enabled]
FW: Supported [enabled]
Rates: 4x 2x 1x [4x]
Registers: 0x1f000217:0x00000314

С agp от nidia У меня все работало на i815, а когда перебрался на
kt266a то все стало Unsupported [Disabled], пришлось включать agpgart.

Значит, не хотят люди слышать мои мысли, слышат только слова. Я не _против_ факта включения ALSA в ядро. Я _за_ ответственное отношение к внутриядерным интерфейсам. И именно из-за безответственного к ним отношения получаются такие вещи, как временная недееспособность alsa. Загоняя alsa в ядро - проблема не уничтожается, а заметается под коврик. Да, теперь любой патч должен будет содержать кусок, обеспечивающий _компилируемость_ alsa (если меняется что-то, относящееся к ней). А кто будет отвечать, что при этом она работает? Линус - только человек, он не может объять необъятное. Поэтому все равно - в ядре 2.4.n она может работать, 2.4.n+1 - не работать (хотя и компилиться), а в 2.4.n+2 - работать опять, потому что разработчики alsa справились пофиксить. В чем отличие? В том варианте, который мне нравится больше, интерфейс между ядром и модулями очень стабилен. И всякие его изменения оглашаются заранее (в pre ядрах), большими буквами...

Слышать мысли нам не дано. Суждение о них можно сделать из слов.
Твоя идея понятна и разумна. Но, по-моему, ты не учитываешь стиль
разработки ядра - базар. В нем нет централизации, нельзя заранее
что-то предсказать. В нем проще когда все в куче. Проще сделать
один патч с изменениями, чем 10 патчей в 10 разных проектов.
По-этому я думаю, что при такой раскладе больше вероятность, что
alsa в 2.4.n+1 будет работать.

Слышать мысли нам не дано. Суждение о них можно сделать из слов.
Твоя идея понятна и разумна. Но, по-моему, ты не учитываешь стиль
разработки ядра - базар. В нем нет централизации, нельзя заранее
что-то предсказать. В нем проще когда все в куче. Проще сделать
один патч с изменениями, чем 10 патчей в 10 разных проектов.
По-этому я думаю, что при такой раскладе больше вероятность, что
alsa в 2.4.n+1 будет работать.

Не понятно, причём тут стиль разработки?
Если будут жесткие интерфейсы для драйверов,
и документация к ним, да к тому-же контроль версионности
то это только облегчит работу. Никто ведь не станет оспаривать, что фиксированный интерфейс облегчает программирование? Или что программы нужно разбивать на объекты, функции процедуры и модули, а не пихать всё в один файл.
Нахрена делать 10 патчей в 10 проектов, при жёстком то интерфейсе модулей драйверов? Если что-то не так в ядре то патчить нужно ядро. Если драйвер не пашет - виноват производитель драйвера.
А вот если чёткого интерфейса нет, тогда действительно все подряд патчить придется, да ещё и разбираться из-за чего ошибки.

Нужно голое ядро и удобный грамотный интерфейс для дайверов: сеть, звук и т.д. и отдельно драйверы, чтобы качать то, что нужно, а не всё подрят. Данные ядра выглядят не как ядра для пользователя, а как ядра для разработчиков. (2.0.х, 2.2.х, 2.4.х)

2svu&all Есть такое мнение что svu и многие другие не до конца понимают опасность фиксированных или строгих интерфейсов !!! Интерфейс аналогичен государственным границам. Если их(границ) много нагорожено то сдерживается перемещение капиталов/раб силы и др. А в ядре это ОЧЕНЬ быстро - при таких лозунгах(Хор. интерфейс лучьше хор. реализации) приводит к "застаиванию" кусков кода, появления обвязок и др. В общем на поддержание этих интерфейсов уходит много энергии. Более того - в стиле разработки линуха (накодили - проверили - накодили - проверили ....) как раз получается что это накодили увеличивается на порядок. То есть вместо того чтобы решать конкретную проблему сейчас приходится разрабатывать интерфейсы - то есть решать общую проблему. Но при таком подходе мы упираемся в точность предсказания ! То есть если мы облажались - либо все переписывать с НУЛЯ либо растет код, происходит черезмерное усложнение итд..... А точность этих предсказаний - хреновая. И в настоящий момент все развивается во многом ТОЛЬКО по тому что было принято правильное стратегическое решения - хаотичноая дарвиноская модель разработки - иначе базар. Альтернатива - ОС где прописаны интерфейсы - HURD. И хреновая надо сказать альтернатива - с практической точки зрения.

А я согласен со svu. Множество мелких модулей при стабильном неизменном (в пределах одной ветки, разумеется) интерфейсе поддерживать будет легче. Больше разработчиков сможет работать, а бинарные драйвера не так страшны. У меня nVidia из иксов не падала, vmware работала нормально. Думаю, в любом случае будет альтернатива между opensource и закрытыми бинарниками. Кто говорит, что альтернатива --- это плохо? :)

А то ведь невольно на ум приходят майкрософтовские средства борьбы во времена ДОСа, когда некоторые досовские вызовы менялись ради того, чтобы добиться несовместимости с конкурентами...

PS Как-то я после make modules_install не смог сразу запустить X, бо инсталлятор потер драйвер nvidia...

С другой стороны, постоянно меняющиеся интерфейсы отталкивают сторонних разработчиков. Если разработчик не уверен, будет ли его софт работать с будущими версиями (опять же, хотя бы в пределах одной стабильной ветки) ядра, то на хрена ему писать под такую ОС? Это просто бардак получается, отталкивается помощь сторонних производителей драйверов. Как следствие, и производителей другого софта.

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

Если гора не идет к Магомету, то Магомет идет к горе.

to svu:

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

Вот когда к тебе Adore навесят, тогда будешь проклянать
модули... :)

2MrBool: А кто такой Adore?

2CybOrc: Спасибо за поддержку.

2kernel: Я начал с того, что не фанат HURD. Хотя и микроядра имеют свою ценность и привлекательность. И HURD, который плох "с практической точки зрения" - совсем не так ужасен архитектурно, как может стать линух, если Хозяин положит в ядро все, что туда можно положить. Да, интерфейсы нужно разрабатывать. На это нужны время и усилия (в основном - /dev/brain). И, действительно, некоторая зависимость от точности предсказаний есть. Но это же не навеки! Обеспечьте стабильность хотя бы стабильной серии ядер - и, возможно, коммерческих драйверов станет больше! И всяким XFS/JFS/... полегчает ("А где взять XFS для 2.4.18pre345?" "Еще не вышел, есть только для 2.4.18pre233!"). Предсказания на пару лет - это же не смертельно. И, уж если сильно облажались с предсказаниями - так и скажите. Громко (чтобы все услышали) - и поменяйте. Я - не сторонник застывших форм. Я - сторонник определенных, оформленных, менеджируемых интерфейсов.

Кстати, про микроядра. Их главный бич, насколько знаю, - скорость. Много переключений между пользовательским и суперуровнем. Линух - монолит и ему не страшна эта болезнь. Но вот взять от микроядер идею интерфейсов ... (дальше, боюсь, начну по новой:)

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

>PS Как-то я после make modules_install не смог сразу запустить X,
>бо инсталлятор потер драйвер nvidia...

Этого не может быть... наверняка этот модуль остался в
/lib/modules/<номер версии ядра>/kernel/drivers/video. Ну
а со сменой версии ядра, старый модуль NVdriver ничем
и так бы не помог, всеравно бы пришлось заново собирать
с новой версией ядра....

> PS Как-то я после make modules_install не смог сразу запустить X, бо инсталлятор потер драйвер nvidia...

Ну и?... Это все равно что руками сказать на него rm -f, а потом жаловаться - "ой, стерлось". Думайте, прежде чем команды от рута писать:))) В makefile хотя бы заглянули для приличия..

Кстати сама nVidia рекомендует драйвер пересобирать после любых изменений в ядре, а тем паче при его смене.