Ваши вопросы Грегу Кроа-Хартману (Greg Kroah-Hartman)

и вот ещё что вдруг спросить захотелось:
-есть ли у вас "настольные" книги? если да, то какие именно?
-попадались ли вам хорошие качественные книги, посвящённые Linux-программированию, которые вы можете особо отметить и прокомментировать?
-как вы относитесь к таким ныне модным и популярным технологиям и методологиям разработки ПО, как agile development, test-driven development, extreme programming, design patterns, и т.д.? Применяется ли что-то подобное (если да, то что именно; если нет, то почему) в процессе разработки ядра?

Если ещё поезд не ушёл, такой вопрос вдруг заинтересовал:
-насколько мне известно, когда команда разработчиков какого-либо дистрибутива берёт ванильное ядро и добавляет в него свои патчи, улучшая некоторые "характеристики" ядра для своего дистрибутива, они обращаются к "ванильным" разработчикам - "вот, смотрите, мы написали этот, этот и тот патчи - если хотите, можете взять их к себе в ванильное ядро"; но если такого (обращения) не происходит, бывает ли так, что разработчики из команды ванильного ядра сами отслеживают появление новых патчей к ванильному ядру у основных, так называемых "мэйнстримовых" дистрибутивов, и "забирают" наиболее "приглянувшиеся"? Другими словами, есть ли взаимодействие со стороны разработчиков ванильного ядра в сторону разработчиков дистрибутивных ядер, если вторые не "размахивают" своими патчями в LKMLе? И если такое взаимодействие есть, то как оно осуществляется?
=======
извиняюсь, что, возможно, слишком сумбурно получилось, но основная мысль вопроса, думаю, ясна :-)

Скажите, возможно ли включение Chrome9 DRM модуля в ядро, если да то, входит ли это в планы?

Существует ли возможность назначить на обработку событий (от)монтирования файловых систем внешний скрипт, а если такового в настоящее время не существует — когда появится подобная функциональность?

Когда будет решена проблема с тормозами (практически зависание) при высокой I/O нагрузке на чипсетах nForce, при версии ядра > 2.6.18?

Тема:Получение открытых спецификаций на оборудование и продвижение Linux на десктоп.

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

На мой взгляд производители компьютерных игр нехотят писать игры под Linux не
из-за запрета на статическую компиляцию библиотек(т.к. можно выпустить проприентарную версию
libc и т.п.),а из-за того что это не даёт им,при малости рынка Linux,видимых приимуществ.
А приимущество есть и значительное.Моё видение ситуаций состоит в том,что поскольку
во время игры другими программами пользоваться неудобно,то игру можно выпускать
без особого ушерба для пользователей в виде LiveCD или флешки,без установки игры
в компьютер пользователя.При этом если зашифровать раздел в который установленна
игра с системой,то для пользователя будет затруднён взлом игры для нелицензионного
копирования,или,если игра сетевая,то для разработки и использования читов.
Но вот беда,ключ для шифрования может быть найден в ядре,в обшем,как нибудь добыт.
Как решение можно бы в дополнение к шифрованию сделать собственный драйвер файловой
системы,и чтобы взломать игру,а потом запустить дебаггер или чит потребовалось бы сначала
этот драйвер заново написать,но GPL обязывает раскрыть код драйвера,что делает возню с
Linux для производителя игры бесмысленной.
Поэтому я предлагаю разрешить писать проприентарные модули файловых систем,спецально
написанные для установки и распространения игры, применение которых разрешать только на
LiveCD с выпускаемой игрой(чтобы случаем не стали стандартом де факто),но в обмен
на эту уступку потребовать полного описания используемого апаратного обеспечения,вплоть
до последнего джойстика,и снятие патентных ограничений на его использование,
покрайней мере в игравой его части.
И так разрешив писать проприентарный драивер фс. мы будем иметь
следуюшее
*)для производителей
1)перенос зашиты игры с апаратного на уровень драйвера фс. позволит получать защиту,
более вломостойкую чем старфорц,так как драйвер фс. с одной стороны
более сложен для повторения,а сдругой стороны ещё и более произволен,т.к будет иметь
уникальные для каждой своей версий особенности,которые к тому же можно использовать
для функционирования алгоритмов игры.Игра с неполным драйвером коректно работать не будет
,то игрой можно будет пользоваться только при ПОЛНОМ повторений драйвера фс.
2) пользователь не будет иметь прямого доступа к системе и сможет запустить чит
или дебаггер не раньше чем будет повторен драйвер фс,что от него потребует больших усилий.
5)Через драйвера можно будет сделать привязку игры к поколению машины.(Ну это будет свинство)
6)Запрет на статическую компиляцию проприентарных кодов с открытыми будет
иметь слабое влияние на зашищённость игры.
*)для пользователей
1)Так как работать можно будет с любого носителя.то можно будет не
бояться за сохранность оригинального носитиля.
2)Крах игры не будет крахом сторонних данных пользователя.
3)Пользование компьютером будет не сложнее,чем обычной игровой
приставкой,при том что компьютер как правило её мощьнее.
*)
Для Linux
1)Так как использование других проприентарных модулей ядра будет запрешено,
то появяться своевременные и полные спецификаций на игровое оборудование,
графические и звуковые карты.
2)На производителей графических карт и прочих устройств производителями игр будет
оказанно давление,с тем чтобы они выпускали полные и своевременные открытые спецификаций
оборудования.
3)Будут заказы на разработку оригинальных скриптов для конфигураций
системы и оборудования.
PS.
Для веруюших ортодоксов:
Warcrafst разве не заслужила скромный гонорар,хотя бы тем,как поддерживает игру?
И тем,что качество кода в отличий от нашей "Сферы",позволяет запускають игру под wine.
А ведь есть ещё читеры которых и бьют и на пиратских серверах.

-какие инструменты вы используете в повседневной работе (дистрибутив/DE/WM/программы/утилиты/..)?
-какое оборудование каких производителей у вас имеется (десктоп/лаптоп/нетбук/кпк/..)? Под управлением каких ОС они работают?
-сколько приблизительно строк кода для ядра вы пишите в день?
-есть ли у вас какие-либо другие СПО проекты, помимо ядра, в которых вы принимаете активное участие?
-что вы думаете об "облачных вычислениях", есть ли у них, по вашему, будущее, и какую роль ядра Linux вы видите в их развитии?
-что может, по вашему, заставить производителей оборудования охотнее делиться спецификациями и сотрудничать в разработке драйверов под Linux?
-чем вы занимаетесь в свободное от работы время? есть ли у вас хобби и увлечения, не связанные с ПО и разработкой?
=======
а ради интереса - при каких обстоятельствах будут задаваться вопросы? при личной встрече на каком-то мероприятии или по интернету? если первое, то что именно за мероприятие?

Появится ли в udev более вменяемый формат правил?
Файлы с сотнями строк вида

BUS=="usb", SUBSYSTEM=="block", KERNEL=="sd*", ACTION=="add", NAME="%k", GROUP="disk", RUN+="/etc/udev/scripts/udev-flash-mount add %k"

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

Не мог никогда понять чем udev демон, лучше devfs? Добавилось устройство, ядро запустило hotplug программу и сказало что за девайс бил додан а хотплуг зделал свое() и сказал досвидание.

Are there any chance to see in Linux the still revolutionary OS design concepts of UNIX 2 (Plan 9, Inferno)? Maybe in Linux 3.0?

Когда же вендекапец?

Будет ли что нибудь подобное?
Встроенную поддержку распределённых сетевых вычислений по умолчанию.
Динамический переход из realtime в защищённый режим, когда надобно.
____
Kernel-inside support rapredelennye network computations by default

Dynamic switch from realtime to protect(?)/timer mode on require.
P.S. sorry for my terrible english.

Отсутствие поддержки какого-либо оборудования в Linux обычно связано с отсутствием спецификации. Но почему тогда например для тех же открытых видеочипов intel до сих пор такие говняные дрова?

интересно было бы услышать о каких ни будь новшествах в ядре Linux, а так же он интересна динамика развития Linux.