Partner Linux Driver Process

Я неправильно сказал. Роадмапа у ядра нет (CMIIW). Хорошо б, если б он был (и тогда уж плательщики нашли б способ его рулить). Но это опять-таки в духе М-ра Торвальдса - развивать продукт, не имея четкого плана...

>> У них еще недавно была программа перевести все свои компы на линукс,
> как показали в галерее: $ sudo nmap -v -O -sS novel.com
Running: Microsoft Windows 2003/.NET OS details: Microsoft Windows 2003 Server SP1
> $ httptype www.novel.com
Microsoft-IIS/6.0
> Настоящие пацаны пользуют венду, а линух впаривают лишь клиентам?

Сеньерас Кретинас! http://www.novel.com это не http://www.novell.com , а совершенно другая компания.
Если разница в одну букву до сих пор не видна - учитесь пользоватся whois.
Interland, Inc. != Novell, Inc.

А вы посмотрите: sudo nmap -v -O -sS novell.com

О ужас, там венда! (точнее 85% ее :) Лично я сильно возмущен, шутка.

Кстати, а как этот нмап пытается догодаться какая там ось?

я не понимаю, почему нельзя стабилизировать API, ведь жить станет проще всем. И ядру не надо будет тонны исходников с собой таскать. Даже если исходник открытый, то почему обязательно должен стоять компилятор, чтобы его собрать? прочему нет бинарных версий (например для "ядер серии 2.6.х")? это было бы удобно.

потому что придется тормозить развитие вперед излишней обратной совместимостью и таскать в исходниках old compatibility crap.

> прочему нет бинарных версий
> "ядер серии 2.6.х"
- ядра серии 2.6.x очень динамично развиваются (и меняются)
- бинарные ядра без исходников не приветствуются

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

> потому что придется тормозить развитие вперед излишней обратной совместимостью и таскать в исходниках old compatibility crap.

Никто не требует ВЕЧНОЙ стабильности API! Но хотя бы ограниченную по времени стабильность можно обеспечить??? Есть стабильная серия - в ней стабильный API. Есть серия devel - в ней все ломается 10 раз на дню. Нет, надо М-ру Торвальдсу все свои решения обкатывать в стабильной серии (а как же иначе, тестеров-то на нечетные серии всегда не хватало!) А все потому что "Linux Not Designed; It Never Was". Нате, кушайте...%((

Похоже Linux пора делиться. Пусть будет существовать две ветки:

1) одна условно только для десктопов с сопуствующими и неизбежными в этом случаями "полезными" программками типа вирусов и антивирусов,

2) а вторая ветка будет свободной

Только бы это конкуренция была констуктивной. Debian в любом случае выживет.

> Просто научитесь читать пару простых (маленьких) файлов в Documentation.

можно *прямую* ссылку на указанный файл с описанием vfs_permission? в пределах Documentation. конкретная версия Linux на ваше усмотрение.

ps: архив с ядром естественно снят с kernel.org. или у вас как-то по другому?

// wbr

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

> А оно нам надо этот индастриал? Опенсорс - это развлечение, а не конвеер.

все-таки не стоит путать OpenSources как таковой и конкретно Linux как его маленькую частность. AFAIU разговор идет именно о Linux и я бы предпочел оставаться в указанных рамках. инече он будет совершенно безпредметным и потеряет всякий смысл.

охотно верю, что для кого-то Linux до сих пор развлечение на уровне just for fun. и если бы такой подход разделяло большинство реальных пользователей системы, вопроса бы не возникало. бога ради, на то он и fun, нет проблем.

но проблема IMHО в том, что de facto Linux уже достаточно давно отнюдь *не* just for fun. с легкой руки RedHat и Novell на базе их продуктов в мире *уже* построено достаточно большое количество самых различных коммерческих систем, которые помимо базовой функциональности зачастую требуют весьма специфичных решений и готовы за это платить живые деньги. guaranteed real time data ptotection как весьма частный случай.

естественно, что при наличии спроса рождается предложение и в игру вступают те самые 3d party группы, которые готовы разработать, внедрить и поддержать желаемое. естественно, что отнюдь не за бесплатно и с вероятностью 99.9% идеи open sources идут лесом. that's the business, Luke. просто свои правила игры, ничего личного.

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

пардон, но если содержимое Documentation/, исследование исходников ядра, личное общение с разработчиками системы и "$ man google" - это все, что аппоненты могут предложить в качестве основных источников информации, это весьма печально. видимо, вы до сих пор не встречались с хорошей документацией на продукт или же подходите к обсуждению сугубо субъективно и biased.

несомненно, есть несколько вполне приличных книг, описывающих внутреннюю структуру ядра. например, "Linux Device Drivers" или "Understanding the Linux Kernel". пользу указанных книг и я ни чуть не умаляю, но книги - это *не* сопроводительная техническая документация на систему и они в принципе не могут ее заменить. это попросту совершенно разные вещи и могут лишь дополнять друг друга, но отнюдь не заменять.

// wbr

> прочитал, ниче не понял. в чем сущносить данной программы- в работе новела с узким числом производителей и об информировании их заранее об сменах api ядра? или что? что-то я не увидел никаких разумных технических решений по ссылке.

боюсь, обсуждение в этой ветке уже давно не имеет никакого отношения к новости по ссылке :)

// wbr

Ну так юзайте Debian stable. Там ядро до следующего релиза стабильно. Только патчи безопасности и накладываются :)

> можно *прямую* ссылку на указанный файл с описанием vfs_permission?

Конечно можно: Documentation/DocBook/man/vfs_permission.9.gz После выполнения make mandocs естественно.

И персонально для вас http://pazke.donpac.ru/kernel-man/vfs_permission.9

> естественно, что при наличии спроса рождается предложение и в игру вступают те самые 3d party группы, которые готовы разработать, внедрить и поддержать желаемое. естественно, что отнюдь не за бесплатно и с вероятностью 99.9% идеи open sources идут лесом. that's the business, Luke. просто свои правила игры, ничего личного.

Проблемы ВАШЕГО бизнеса разработчикам ядра совершенно не интересны. Никто вас из под палки linux использовать не заставляет.

> и рассматривая Linux именно с точки зрения стороннего разработчика, которому в силу текущих веяний рынка приходится разрабатывать ПО под указанную систему,

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

> несомненно, есть несколько вполне приличных книг, описывающих внутреннюю структуру ядра. например, "Linux Device Drivers" или "Understanding the Linux Kernel". пользу указанных книг и я ни чуть не умаляю, но книги - это *не* сопроводительная техническая документация на систему и они в принципе не могут ее заменить. это попросту совершенно разные вещи и могут лишь дополнять друг друга, но отнюдь не заменять.

Вы не ответили на вопрос какую именно коммерчекую ОС вам удалось осилить во всех подробностях, без покупки книг, всяких sdk/ddk, гугла и приставаний к знающим людям. Пример в студию !

> Проблемы ВАШЕГО бизнеса разработчикам ядра совершенно не интересны.

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

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

> Никто вас из под палки linux использовать не заставляет.

работать с этой системой "заставляет" рынок. как уже было сказано, есть спрос - появляется и предложение.

> Ну так и купите себе лицензионный QNX, отсегивайте им бабки и наслаждайтесь.

распространенность систем на базе QNX [вне зависимости от его версии] минимальна в сраврении с Linux или Solaris. это, мягко говоря, не те объемы. если вдруг ситуация поменяется в сторону QNX - это будет повод для обсуждения. но не ранее.

> Или хочется всего и нахаляву ?

пардон, причем тут холява? известные мне заказчики используют Linux в своих решениях отнюдь не нахаляву. как правило, стоят честно купленные готовые решения от RedHat или Novell. IMHO вполне естественное желание иметь техническую поддержку хотя бы в виде вменяемой документации на систему к холяве никакого отношения не имеет.

> Вы не ответили на вопрос какую именно коммерчекую ОС вам удалось осилить во всех подробностях, без покупки книг, всяких sdk/ddk, гугла и приставаний к знающим людям. Пример в студию !

по крайней мере из моего опыта с точки зрения DDK - это QNX6 и MS Windows. несомненно, и тут отнюдь не все так шоколадно, но тем не менее дела обстоят заметно лучше. ну а если говорить про SDK, то тем более, рвут как тузик грелку.

да и почему собственно вы решили, что я против покупки SDK/DDK? пожалуйста, если у вас есть a'la DDK для платформ на базе Linux, я с интересом рассмотрю это предложение.

// wbr

>Я неправильно сказал. Роадмапа у ядра нет (CMIIW). Хорошо б, если б он был (и тогда уж плательщики нашли б способ его рулить). Но это опять-таки в духе М-ра Торвальдса - развивать продукт, не имея четкого плана...

Roadmap есть у отдельных подсистем. Напрмер недавно был wireless summit, где были представители корпораций вроде RH/Novell/IBM и другие. Но как ни странно, маинтейнер wireless-dev - John Linwill (если не ошибся в написании фамилии), который ни в одной из них не работает. И все потуги протолкнуть Intel'овские идеи идут лесом (хотя все, что связано с ipw[23]xx с удовольствием принимают).

Такой же roadmap есть и у desktop devision, но как ни странно, наиболее активен в этом направлении Dave Airlie, который тоже не работает ни в Novell, ни в RH, ни в IBM и т.п. (Кстати, он один из авторов поломанного r300).

Много таких же историй я могу рассказать про network, sata, VMM.

>svu *** (*) (19.05.2006 0:20:36)

>> Просто научитесь читать пару простых (маленьких) файлов в Documentation.

>можно *прямую* ссылку на указанный файл с описанием vfs_permission? в пределах Documentation. конкретная версия Linux на ваше усмотрение.

>ps: архив с ядром естественно снят с kernel.org. или у вас как-то по другому?

Documentation/DocBook/man/vfs_permission.9.gz (требует make mandocs)

Documentation/kernel-doc-nano-HOWTO.txt -> scripts/kernel-doc -man fs/namei.c > /tmp/namei.9 (получили ман, в котором есть vfs_permission)

>klalafuda * (*) (19.05.2006 8:04:16)

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

Все дело в том, что QT несколько проще ядра Linux, QT не работает с различным (постоянно обновляющимся) железом, которое может требовать очень кривые хаки для достижения максимальной производительности или же смену API/дизайна. Но вы, судя по всему, мало работали в этой сфере, раз утверждаете, что можно сделать один раз правильный дизайн и все последубщие аппаратные платформы будут прекрасно в него вписываться.

Если вы в качестве примера приведете solaris, то я всего лишь скажу, что именно Linux работает быстрее на их же собственной платформе (например та же t2000 niagara), чтобы этого достичь, пришлось достаточно много изменить в page fault и tlb miss processing logic в sparc64 архитектуре, а могли бы оставить как было в старых sparc64 (как сделано в solaris, btw, а они этот обработчик взяли из Linux, btw) и получить на ~30% больше кода в page fault trap.

Если вам нужна стабильность и отсутствие новой функциональности - пользуйтесь 2.4, для этой ветки тоже есть книги и документация. Там API не ломается.

>klalafuda * (*) (19.05.2006 9:47:13)

> Documentation/kernel-doc-nano-HOWTO.txt -> scripts/kernel-doc -man fs/namei.c > /tmp/namei.9 (получили ман, в котором есть vfs_permission)

можно было бы и сразу сказать, что конечный man генерится из a'la doxygen коментариев в исходном тексте в fs/namei.c .. ;)

anyway, это уже заметно лучше. к сожалению, конечно же остаются вопросы a'la:

a) как у нас с return value? это 0 vs код статуса, boolean или что-то еще? ограничения на возвращаемое значение и его интерпритация? ограничения на передаваемые параметры? хотя бы mask - это битовая маска или все-таки switch?

b) это не работает в 2.4 :) коментарий там в принципе есть, но стиль [еще?] не doxygen да и описание заметно более куцое. я конечно же понимаю прогрессивность ветки 2.6, но клиентская база под 2.4 еще весьма существенна и никуда исчезать пока что явно не собирается.

// wbr

> Все дело в том, что QT несколько проще ядра Linux

IMHO это очень и очень спорное утверждение.

если не брать в рассчет мишуру драйверов, само ядро Linux с точки зрения системного программиста сравнительно просто и ничего особенного в нем я пока что не увидел [быть может пока?]. скорее, муторное. ну и за coding style я бы.. ну да оставим это.

though that's just IMHO.

ps: разработка драйверов под железо - это, пожалуй, самое простое, с чем я сталкивался :) в 99% случаев все сравнительно просто и тривиально.

// wbr

Спасибо за информацию. И что это на самом деле иллюстрирует? Что процесс разработки ядра до сих пор местами таки да повернут "задом" к корпорациям (что, увы, невозможно не признать - есть такое остаточное явление;). В перспективе это может означать две вещи - либо корпорации повернут его "передом" и таки научатся минимально контролировать процесс, либо однажды их достанет неподконтрольность линусовых лейтенантов - и они начнут форкать. В принципе, то кол-во патчей, которые накладывает редхат - уже признак... И то, что делает Новел - это попытка сделать интерфейс с развитием ядра более "удобоваримым" для бизнеса. Система, которая абсолютно неподконтрольна и развивается как Бог на душу положит - называется "любительской".

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

>Спасибо за информацию. И что это на самом деле иллюстрирует? Что процесс разработки ядра до сих пор местами таки да повернут "задом" к корпорациям (что, увы, невозможно не признать - есть такое остаточное явление;).

Это показывает, что процесс разработки не контроллируется отдельно взятой компанией. Этим процессом движет не желание продать, а желание сделать хорошо (а потом это кто-то может продать).

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

RH в FC накладывает минимальное количество патчей, в основном это новая функциональность вроде xen, 2/2 split (уже в ядре) и т.п. Для RHEL патчей больше, т.к. ядро там меняется реже.

>И то, что делает Новел - это попытка сделать интерфейс с развитием ядра более "удобоваримым" для бизнеса. Система, которая абсолютно неподконтрольна и развивается как Бог на душу положит - называется "любительской".

Linux развитие обусловлено сремлением к качеству (пусть оно и не всегда адекватно), а не к стремлению продать как можно больше инсталляций. То, что вы называете "любительской" системой, создано одними из лучших профессионалов в мире, и то, что кто-то не может их контроллоировать и заставлять плясать под свою дудку, всего лишь проблема корпорации.

Корпорации не могут контроллировать Linux, они всего лишь движутся вместе с ним.

>Да, кстати, есть обратная сторона медали - хаотический процесс разработки дает возможность компаниям типа Новел зарабатывать на этом деньги. Но я не уверен, что это годится как long term solution.

Lonm term - это сколько? Последние 10 лет все больше и больше компаний стремятся к Linux, но не наоборот. Linux становится популярнее не потому, что его рекламируют, а потому, что модель разработки, основанная на стремлении к качеству, позволяет создавать продукт, являющийся _ЛУЧШИМ_ во все больших областях.

>svu *** (*) (19.05.2006 11:22:08)

> Lonm term - это сколько? Последние 10 лет все больше и больше компаний стремятся к Linux, но не наоборот. Linux становится популярнее не потому, что его рекламируют, а потому, что модель разработки, основанная на стремлении к качеству, позволяет создавать продукт, являющийся _ЛУЧШИМ_ во все больших областях.

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

ps: "лучшее" - понятие черезвычайно относительное и субъективное и применимо лишь к конкретно взятому случаю с учетом массы частных деталей. вы никогда не встречали терабайтные системы под MS Exchange? самое смешное, что ведь работают и даже вполне стабильно. почему - не знаю :) причем что это далеко не самое страшное и толстое, что можно придумать и воплотить..

// wbr

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

Если продолжать аналогию с Qt, вы должны требовать от Qt cтабилизации и описания всех внутрибиблиотечных интерфейсов. А ведь даже в публично доступном api qt происходили весьма существенные изменения при переходе с версии 2 на 3, и c 3 на 4. Ну не хотят разработчики обрастания библиотеки грязными хаками для обратной совместимости. В случае с ядром все еще краше ибо qt имеет дело со стабильными интерфейсами x11, winapi и т.д, а ядро с постоянно появляющимися устройствами, чипсетами и даже новыми архитектурами процессоров. Учитывая это установить и задокументивать во всех подробностях (и тем более наоборот) внутриядерный api без торможения развития и обрастания системы мириадами хаков нереально.

Кстати ПМСМ вышеописаные обстоятельства сыграли немалую роль в смерти портов WinNT на mips, powerpc и alpha. А qnx например так и вообще никуда непортабелен.

В общем пользовательский api предоставляемый ядром описан вполне адекватно. Внутриядерный api не является (и не будет) полностью стабильным и создание отдельной от ядра документации достаточно затруднительно. Такова жизнь.

>"лучшее" - понятие черезвычайно относительное и субъективное и применимо лишь к конкретно взятому случаю с учетом массы частных деталей. вы никогда не встречали терабайтные системы под MS Exchange? самое смешное, что ведь работают и даже вполне стабильно. почему - не знаю :) причем что это далеко не самое страшное и толстое, что можно придумать и воплотить..

Безусловно, понятее "лучшее" достаточно субъективно, и должно включать описание условий работы, поэтому я и написал, что Linux становится лучшим в определенных областях.

MS мог бы создавать очень неплохие вещи, но т.к. в этой компании _все_ разработки, попадающие к конечному пользователю, движутся исключительно желанием побольше продать, то сам процесс разработки получается "как можно больше и быстрее". Поэтому в определенных условиях продукты MS отлично работают, но в целом ситуация с ними плачевная.

>klalafuda * (*) (19.05.2006 11:38:44)

> Если продолжать аналогию с Qt, вы должны требовать от Qt cтабилизации и описания всех внутрибиблиотечных интерфейсов.

пардон, я не совсем понял - почему именно внутренних интерфейсов?

API ядра, доступное из загружаемого модуля - это отнюдь не внутренние интерфейсы, это как раз публичные интерфейсы для 3d party вендоров. именно их я имею ввиду. а не детали конкретной реализации, например, dcache. хочется качественного описания синтаксиса и семантики публичного API и неизменности его в течении какого-то разумного периода времени [хотя бы пару-тройку лет]. И, что самое важное, чтобы описанное соответствовало действительности на протяжении срока его жизни без изменения синтаксиса или семантики операций. ну и, само собой, при внесении изменений в то или другое просто необходимо *одновременно* внести соотв. изменения в документацию на интерфейсы.

> А ведь даже в публично доступном api qt происходили весьма существенные изменения при переходе с версии 2 на 3, и c 3 на 4.

тогда по аналогии о полной совместимости 2.2 -> 2.4 -> 2.6 я даже не мечтаю и этот вопрос на повестку дня не ставится. хотя было бы конечно же просто замечательно, кто спорит. но нужно быть реалистом.

> В случае с ядром все еще краше ибо qt имеет дело со стабильными интерфейсами x11, winapi и т.д, а ядро с постоянно появляющимися устройствами, чипсетами и даже новыми архитектурами процессоров.

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

> А qnx например так и вообще никуда непортабелен.

:))) вне всяких сомнений, поддержка QNX6 платформ на базе x86, PPC, SH4, MIPS32 и различных разновидностей ARM не в счет :)

http://www.qnx.com/developers/hardware_support/index.html

> В общем пользовательский api предоставляемый ядром описан вполне адекватно. Внутриядерный api не является (и не будет) полностью стабильным и создание отдельной от ядра документации достаточно затруднительно. Такова жизнь.

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

на счет "нереально".. очень спорный вопрос. never say never :) другое дело, если вполне конкретные и живые люди просто не в состоянии поддерживать ее в адекватном состоянии. даже не суть важно, по какой именно причине. но "нереально" вообще - это конечно же сильно сказано. just nobody gives a fuck about it. тогда конечно же да, проблемы на лицо.

// wbr

> отдельно взятой компанией

С этим я не спорю. Мало что в линухе контролируется отдельно взятой. А вот набором договорившихся компаний (АКА картель%) - многое.

> Для RHEL патчей больше, т.к. ядро там меняется реже.

Я как раз об этом. Как только нужна стабильность - появляются патчи. Разве это хорошо? Те, кто платят деньги, хотят за свои деньги гарантий. Отношение "заплатил - теперь иди отсюда" работает очень недолго.

> Linux развитие обусловлено сремлением к качеству (пусть оно и не всегда адекватно), а не к стремлению продать как можно больше инсталляций.

Ядра - возможно (пока что). Всего стека ОС - нет. Есть сильно подозрение, что контроль корпораций над ядром - вопрос времени. Кстати, Линус работает на OSDL. Кто туда деньги вкладывает? За красивые глаза?;)

> Последние 10 лет все больше и больше компаний стремятся к Linux, но не наоборот

Расскажите мне про "сферический Линукс", который никуда не стремится. В котором нет места Редхату, Новеллу, Сану и IBM. Жабке и гному. Сколько, говорите, было машин с установленным линухом в каком-нибудь 1995г? Мы популярны только потому что у нас такое замечательное ядро?;)

> Linux становится популярнее не потому, что его рекламируют, а потому, что модель разработки, основанная на стремлении к качеству, позволяет создавать продукт, являющийся _ЛУЧШИМ_ во все больших областях.

Я не стану утверждать, что линух худший (хотя я б не взял на себя смелость называть его лучшим). Но популярность в наше время - практически всегда результат маркетинга, на 99%. Уже очень давно популярность не является следствием чисто технических преимуществ (OS/2, ау!). Если б ESR не написал свой "собор и базар" (маркетинговый текст, не технический!) - начальное множество "просветленных" компаний не сложилось бы.

> MS мог бы создавать очень неплохие вещи, но т.к. в этой компании _все_ разработки, попадающие к конечному пользователю, движутся исключительно желанием побольше продать, то сам процесс разработки получается "как можно больше и быстрее". Поэтому в определенных условиях продукты MS отлично работают, но в целом ситуация с ними плачевная.

вы наверное не встречались с работой compatibility team из MS :) оч суровые ребята и без их активити был бы вообще полный п&^%^$ в кубе. другое дело, что по сравнению с Linux, количество продуктов для тестирования на совместимость под Windows приближается к бесконечности и даже эти ребята не всегда справляются с потоком данных.

ps: я отнюдь не спорю с тем, что MS оч желает продавать свои продукты :)

// wbr

2 logIN

> Это пока они разрешают реверс инжиниринг, подкармливают так сказать.

Это где ж они разрешают RE ? В лицензиях аглицким по белому написано, что низзя. Причем, это стандартный пункт любой закрытой лицензии. Просто они не обращают на это должного внимания.

> Linux развитие обусловлено сремлением к качеству

Расскажи эту сказку товарищу Мортону, выступавшему не так давно.

Это еще можно было бы сказать про 2.4. Про 2.6 можно сказать только одно - разброд и шатание.

> Если продолжать аналогию с Qt, вы должны требовать от Qt cтабилизации и описания всех внутрибиблиотечных интерфейсов. А ведь даже в публично доступном api qt происходили весьма существенные изменения при переходе с версии 2 на 3, и c 3 на 4. Ну не хотят разработчики обрастания библиотеки грязными хаками для обратной совместимости.

Здра моя ра... Видимо, некоторые не в курсе, что с Qt 2.x шла библиотека обраной совместимости с Qt 1.x. Аналогичные библиотеки есть и в Qt 3.x и в Qt 4.x.

>технических преимуществ (OS/2, ау!).

и какие у нее технические преимущества?

>вы наверное не встречались с работой compatibility team из MS :)

ага как они ради какой-то игрушки прогнулись,
она что-то типа после free использовала память,

и они в загрузчик exe файлов добавили код по определению что именно эта игрушка загружается и именно ей разрешили использовать память после free. Кому нах нужна такая совместимость?

и чем http://www.novel.com отличается от www.novel.com,
с точки зрения сканера?

>Странный ты человек... Проверь кого сканишь.

Сканиться теперь www.novel.com разве не видно?

http://www.novell.com/ Два LL!

Да что им про два L рассказывать. Уже сколько людей на это указало. Уже сколько раз их обматерили. Сразу видно - они кащениты :)

>API ядра, доступное из загружаемого модуля - это отнюдь не внутренние интерфейсы, это как раз публичные интерфейсы для 3d party вендоров. именно их я имею ввиду. а не детали конкретной реализации, например, dcache. хочется качественного описания синтаксиса и семантики публичного API и неизменности его в течении какого-то разумного периода времени [хотя бы пару-тройку лет]. И, что самое важное, чтобы описанное соответствовало действительности на протяжении срока его жизни без изменения синтаксиса или семантики операций. ну и, само собой, при внесении изменений в то или другое просто необходимо *одновременно* внести соотв. изменения в документацию на интерфейсы.

За последние 3 года поддержки некоторых драйверов (все достаточно простые char based devices) я только менял доступ к sysfs (class attributes), да и то можно было бы статически задать major number.

По сравнению с чтением LOR (который я читаю около полугода) потраченное на изменения драйверов время просто незаметно :)

> И все что вы можете сказать по теме? Значит доков нет и линукс кучка лицемеров котоыре пытаются навязать мне свою политику постоянно ломая интерфейс и не делая доков. Это политика у них такая.. Лицемеры одно слово.

Лицемеры, где доки, почему нет доков? -Иди туда где есть доки, тебя сюда никто не звал :)

Почему постоянно ломаете интерфейс, не делая доков, это же отстой? -Иди туда где интерфейс не ломают, здесь тебе никто не должен. :)

Меня все устраивает, я понял преимущества открытого софта, хочу сказать разработчикам спасибо :) -молодец, можешь сказать спасибо в камментах на ЛОРе

----------------------- Тинус Лорвальдс

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

А он и не меняется в целом. Незначительные изменения для доступа к sysfs/hotplug исправляются моментально.

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

Она и обновляется в 2.6. Вам же уже показали, что есть man, сгенерированный из doxygen, есть и обычный man. Есть всяческие xml.

>klalafuda * (*) (19.05.2006 12:23:44)

> API ядра, доступное из загружаемого модуля - это отнюдь не внутренние интерфейсы, это как раз публичные интерфейсы для 3d party вендоров. именно их я имею ввиду. а не детали конкретной реализации, например, dcache. хочется качественного описания синтаксиса и семантики публичного API и неизменности его в течении какого-то разумного периода времени [хотя бы пару-тройку лет].

Не будет этого, по крайней мере предпосылок к этому нет и не предвидится. Читайте Documentation/stable_api_nonsense.txt раздел Stable Kernel Source Interfaces, там четко изложена позиция разработчиков ядра. Не нравится уходите с рынка где востребована такая плохая система. Но в любом случае это не проблема разработчиков.

> :))) вне всяких сомнений, поддержка QNX6 платформ на базе x86, PPC, SH4, MIPS32 и различных разновидностей ARM не в счет :)

Уели :)

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

Вам кажется и это от недостатка знаний. Вот придумали вы суперAPI ядра, все вроде хорошо и вдруг бах и выходят процессоры с PAE (Page Address Extension), а у них таблицы страниц не двух, а трехуровневые. Что делать ?

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

А различия в работе с кешами, tlb, в обработке прерываний и т.д. и т.п. ?

Не выйдет у вас продумать API ядра на 3 года вперед. Ибо человеку свойственно ошибаться.

> ну и, само собой, при внесении изменений в то или другое просто необходимо *одновременно* внести соотв. изменения в документацию на интерфейсы.

Это с вашей пиявочьей точки зрения "само собой". С точки зрения разработчиков это дополнительная и не слишком благодарная работа. Ибо всегда найдется какой-нибудь binr, который не прочитав man termios будет возмущаться отсутствием документации. Смею вам еще раз напомнить что разработчики вам лично ничего не должны.

> Здра моя ра... Видимо, некоторые не в курсе, что с Qt 2.x шла библиотека обраной совместимости с Qt 1.x. Аналогичные библиотеки есть и в Qt 3.x и в Qt 4.x.

Это и были собранные до кучи грязные хаки.

>> отдельно взятой компанией

>С этим я не спорю. Мало что в линухе контролируется отдельно взятой. А вот набором договорившихся компаний (АКА картель%) - многое.

Нет картелей, трестов и монополий в Linux. Я же приводил примеры, где там подобные выводы?

>> Для RHEL патчей больше, т.к. ядро там меняется реже.

>Я как раз об этом. Как только нужна стабильность - появляются патчи. Разве это хорошо? Те, кто платят деньги, хотят за свои деньги гарантий. Отношение "заплатил - теперь иди отсюда" работает очень недолго.

Неверно. Патчей в rhel больше не для стабильности, а для расширения функциональности. Заплатил деньги за 2/2 split на 2.6.8 - получите патч.

>> Linux развитие обусловлено сремлением к качеству (пусть оно и не всегда адекватно), а не к стремлению продать как можно больше инсталляций.

>Ядра - возможно (пока что). Всего стека ОС - нет. Есть сильно подозрение, что контроль корпораций над ядром - вопрос времени. Кстати, Линус работает на OSDL. Кто туда деньги вкладывает? За красивые глаза?;)

OSDL наняла Торвальдса, Мортона и других для рекламы - дескать мы open source development lab, поэтому у нас работают мэтры open source (тот же Andrew Tridgell, соавтор samba).

Даже если вдруг Торвальдс скажет, как пример, что Linux отказывается от поддержки desktop, и все будет делать только для ускорения работы серверных систем (а ведь именно этого хотят корпорации, т.к. их доход от open source в подавляющем большинстве состоит из продаж северов), его быстро поставят на место. Люди просто прекратят коммитить в 2.6, и пропадет и desktop, и server - все проиграют.

>> Последние 10 лет все больше и больше компаний стремятся к Linux, но не наоборот

>Расскажите мне про "сферический Линукс", который никуда не стремится. В котором нет места Редхату, Новеллу, Сану и IBM. Жабке и гному. Сколько, говорите, было машин с установленным линухом в каком-нибудь 1995г? Мы популярны только потому что у нас такое замечательное ядро?;)

Пожалуйста, постарайтесь понять, что я вам говорю. Linux разрабатывается по собственной программе, Sun, IBM, RH и Novell всего лишь _ПОМОГАЮТ_ ему в _ЭТОМ_, а не диктуют условия.

Это новая модель, которую вы, судя по всему, не можете/не хотите понимать.

>> Linux становится популярнее не потому, что его рекламируют, а потому, что модель разработки, основанная на стремлении к качеству, позволяет создавать продукт, являющийся _ЛУЧШИМ_ во все больших областях.

>Я не стану утверждать, что линух худший (хотя я б не взял на себя смелость называть его лучшим). Но популярность в наше время - практически всегда результат маркетинга, на 99%. Уже очень давно популярность не является следствием чисто технических преимуществ (OS/2, ау!). Если б ESR не написал свой "собор и базар" (маркетинговый текст, не технический!) - начальное множество "просветленных" компаний не сложилось бы.

ну да, ну да... На днях читал о сравнении t2000/solaris vs. t2000/linux vs. smth-itanium-based...

Маркетинг и корпоративные правила являются _дополнением_ к работе модели развития Linux, а не определяют его.

>svu *** (*) (19.05.2006 12:32:08)

По сравнению с виндоз 3.11 и вин 95 - это была настоящая 32-битная ОС..

> Это и были собранные до кучи грязные хаки.

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

> По сравнению с виндоз 3.11 и вин 95 - это была настоящая 32-битная ОС..

Угу. В которой была куча 16-ти битного бинарного кода. Хотя по сравнению с 3.x... :)

> Ты бы в ядро еще заглянул бы. Там таких хаков куча. Типа: "Вот это должно бы работать вот так, но не работает. Почему - хез. Поэтому я тут набодяжил вот такой мега код, который как-то работает. Как - хез" :)

Уж поверьте я это делаю много чаще вас. Поэтому, пример в студию !

> Маркетинг и корпоративные правила являются _дополнением_ к работе модели развития Linux, а не определяют его.

Гхм. Что-то у нас топик плавает. То мы про направление, то мы про модель. Про модель спорить не буду - она таки да опенсорцевая.

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

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

:) Пожалуй теперь пора. Да, обоюдному согласию мы не пришли...

>svu *** (*) (19.05.2006 13:55:39)

>Ага не в курсе... Что бы отключить frame buffer Documentation не поможет, чтобы отключить dma дока ядра ен поможет.

ложь.