Через год в Linux ядре будет блокирована работа закрытых модулей

Касательно gigabit ethernet driver userspace тестов - он _не_ обрабатывает высокоуровневые протоколы (например как ip), в то время как ядерный драйвер передает данные в сетевой стек (где они успешно выбрасываются, но перед эти проверяется куча контрольных сумм и т.п.), этот userspace драйвер именно потому и работает быстрее (в терминах CPU usage, network performance одинаковый), что не делает никаких обработок входящего потока.

IDE userspace driver тест - копирование 64мб с диска - тест некорректный, т.к. оба драйвера и userspace, и kernelspace уперлись в потолок производительности жесткого диска, но даже при этом видно, что kernelspace масштабируется линейно при росте буфера, а userspace начинает загибаться, и это при том, что они _не_ использовали стандартный аллокатор памяти (который сам по себе не максимально быстр).

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

>Писец, сам себе противоречишь...

Ты меня с кем-то перепутал. Это был мой первый пост по теме.

> Гарантировать может _только_сам_дядя_

Совершенно верно

> И как это он и пишет на железке

А вот это - неверно. Дядя напишет то, что ему выгодно. Если рынок затоварен дорогими картами, и их просто не берут - он напишет на нормальной работоспособной карте entry-level, заблокирует ей пару конвейеров и продаст. Ну, получит меньше прибыли - но всё равно получит.

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

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

так нет же. хотят товарищи купить _свою_ свободу совести за _мой_ счет. ну это ли не сволочизм?

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

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

P.S. 2svu: почему ты так часто говоришь не то что думаешь? это риторический вопрос.

>Значит будет форк торвальдского дерева, в котором все фичи внедрят (в смысле не та лицензия -> пнх)

И будет ещё один зомби, младший брат Hurd-а.... ни жив, ни мёртв.... =\

>> Надо вспоминать - давайте завтра в этом же теме, сейчас пора уходить.

>Договорились

Успел сегодня - ответил выше.

>> Не знаю, на что конкретно вы ссылаетесь

>На книгу "Writing Linux Device Driver, 3rd edition", ее все называют LDD3

На что конкретно? Какой контекст? page_cache_get/release - это увеличение/уменьшение (с освобождением) reference counter.

>> но page_cache_release() это всего лишь освобождение памяти, как free(), оно не имеет никакого отношения к page fault и т.п.

>page_cache_release - это совсем не free. Она unpin страницу кэша страниц, делая эту страницу доступной для page out. Сама она, конечно, page fault не вызывает.

Что? Ядро такой OOPS отпишеь, когда узнает, что pinned page была передана в page_cache_release() при refcnt == 1. Check for free_pages_check().

page_cache_release() этого не делает, она просто уменьшает reference counter, то, что вы странно описали, делает unlock_page().

>>>Да, а переключение контекста - оно может произойти? ;)

>>Когда?

>Я говорю о вашей фразе: "эти регионы останутся в памяти, пока не произошло переключение контекста". Насколько я знаю (и LDD* со мной согласна), переключение контекстов не имеет никакого отношения к тому, остануться ли регионы в памяти - они остануться в ней, пока драйвер явным образом не разрешит им уйти (а может, и дольше - если нет memory pressure).

Страницы "уйдут" только при переключении контекста на kswapd например (или pdflush), но дело не в этом. Они будут помечены как свободные драйвером в любое время, но, касательно нашего обсуждения userspace/kernelspace драйверов, ядерный драйвер не должен их копировать, используюя copy*user(), ему достаточно сделать dma в страницу из vfs cache, а userspace драйвер их оттуда еще и копировать будет, либо будет лочить весь vfs cache, что чудовищно неоптимально.

Видите на графике загиб copy*user() при огромной передаче данных - это именно оно - page fault.

>tailgunner (*) (14.12.2006 21:17:04)

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

Ты неправ. Вот выдержка из взятого наобум гарантийного талона: "Гарантия не распространяется на следующие элементы и поврежднения: 1)бла-бла-бла... ...n) при наличии насанкционированного вскрытия, ремонта, попыток внесения изменений в конструкцию или программноге обеспечение..."

>А кто, йопрст, решил что он ВПРАВЕ РЕШАТЬ ЗА МЕНЯ? о_О

>Хренасе "свобода"....

Да, так часто бывает: на 6-й странице обсуждения появится "настоящий русский мужик, хоть и неграмотный, но мудрый от природы" и, прочитав последние несколько постов, "расставит всё по местам", и "обломает всех философов":)))

s/И как это он/И как раз это он/

> Касательно gigabit ethernet driver userspace тестов - он _не_ обрабатывает высокоуровневые протоколы (например как ip), в то время как ядерный драйвер передает данные в сетевой стек

??? Цитата из статьи: "We did not want to start comparing IP stacks, so none of these tests actually use higher level protocols." Так что (по их словам) никаких контрольных сумм и обработки потока не делали ни ядерный драйвер, ни юзерспейсный.

> IDE userspace driver тест - копирование 64мб с диска - тест некорректный, т.к. оба драйвера и userspace, и kernelspace уперлись в потолок производительности жесткого диска, но даже при этом видно, что kernelspace масштабируется линейно при росте буфера, а userspace начинает загибаться

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

ИМХО, проблема с shared прерываниями - более серьезная..

Но в общем - очень даже многообещающе. Вылизать (и решить проблему с shared прерываниями) - и будет нам счастье.

> товарищ Energizer, которого я очень уважаю за адекватность

Мне жаль, но у Вас устарелая информация.

>> Мы не пустим вас в концлагерь, даже если там солнце ярче, трава зеленее, вода мокрее и сахар слаще.

> А кто, йопрст, решил что он ВПРАВЕ РЕШАТЬ ЗА МЕНЯ? о_О Хренасе "свобода"....

Свобода а-ля фонатег.

>Ты меня с кем-то перепутал. Это был мой первый пост по теме.

Никакой путаницы, противоречие в этом твоём одном-единственном посте. Что написано --- то и гарантировано. Гарантировано только то, что написано. То, что видюха молотит на 20% шустрее при перепрошивке --- это на свой страх и риск, вендор _не_обязан_ отвечать за то, если она накроется нефритовой вазой.

>Дядя напишет то, что ему выгодно

Ё-моё, как ты не поймёшь.... =\

Вот смотри, дяде выгодно давать гарантию 6 месяцев. И пофиг, что реально карты работают годами. Но ты же не пойдешь через год доказывать, что карта на самом деле может работать гораздо дольше, и что дядя оборзел, давая всего год гарантии? ГАРАНТИЯ --- 6 МЕСЯЦЕВ, И ПЛЕВАТЬ, ЧТО ОНА МОЖЕТ РАБОТАТЬ И ДОЛЬШЕ. Соответственно, ГАРАНТИЯ НА ТАКОЙ-ТО РЕЖИМ, И ПЛЕВАТЬ ЧТО ОНА МОЖЕТ РАБОТАТЬ И В ДРУГОМ.

Теперь понятнее?

>Да, так часто бывает: на 6-й странице обсуждения появится "настоящий русский мужик, хоть и неграмотный, но мудрый от природы" и, прочитав последние несколько постов, "расставит всё по местам", и "обломает всех философов":)))

Не знаю кто как, но я если уж читаю, то от начала и до конца =)

Но мне всё-таки интересно, кто считает себя вправе решить за меня "Не ходи туда, там плохо! Пусть там трава зеленее и девки сговорчивее, но я считаю что там плохо и поэтому тебя туда не пущу!"

Ну так в том то и дело, что работает всегда бинарный код. А лицензию предлагается изменить для исходного! Это разные проблемы, Линус об этом и пишет.

> page_cache_get/release - это увеличение/уменьшение (с освобождением) reference counter.

Про page_cache_get я ничего не говорил. Я упоминал get_user_pages.

>>page_cache_release - это совсем не free. Она unpin страницу кэша страниц, делая эту страницу доступной для page out. Сама она, конечно, page fault не вызывает.

>Что? Ядро такой OOPS отпишеь, когда узнает, что pinned page была передана в page_cache_release() при refcnt == 1

К моему стыду, я не знаю, какой там будет reference counter. Скорее всего, get_user_pages увеличит его на 1 (до 2 ;)), драйвер выполнит В/В, а потом page_cache_release уменьшит его до 1, сделав страницу доступной для paging.

> ядерный драйвер не должен их копировать, используюя copy*user(), ему достаточно сделать dma в страницу из vfs cache, а userspace драйвер их оттуда еще и копировать будет, либо будет лочить весь vfs cache

Насколько я понял из статьи, они реализовали специальный системный вызов - usr_pci_map, который просто обертка pci_map_sg, так что копировать им не придется - драйвер зафиксирует страницы в памяти, и начнет DMA прямо в них.

".... Вообще, после религиозных проповедников (которые стучатся в дверь, чтобы сказать мне, во что я должен верить) меня больше всего раздражают люди, которые стучатся в дверь (или бомбардируют меня мейлами), чтобы объяснить, как я должен лицензировать свои программы. Это не политический вопрос. Каждый должен иметь право на собственное мнение. Одно дело — предложить применить к программе GPL и на этом остановиться. А другое дело — затевать спор по этому поводу. С какой стати люди возмущаются тем, что я работаю на коммерческую фирму, которая не распространяет все свои материалы на условиях GPL? Я им говорю, что это не их дело.
Больше всего в Ричарде меня раздражает не то, что он требует сменить название Linux на gnu/Linux, потому что ядро Linux опирается на приложения из проекта gnu. И не его открытое возмущение тем, что я стал знаменем движения за открытое программирование, хотя он следовал этим принципам, еще когда я спал в бельевой корзинке. Нет, меня бесит то, что он постоянно ругает всех, кто не использует GPL.
Издали я восхищаюсь Ричардом по множеству причин. И вообще мне нравятся люди с твердыми моральными принципами, как Ричард. Но почему они не могут держать эти принципы при себе? Больше всего я не люблю, когда мне говорят, что делать и чего не делать. Я полностью отвергаю людей, которые полагают, что имеют право влиять на мои решения...." Linus Torvalds, "Just for fun"

> Ё-моё, как ты не поймёшь.... =\

Я тупой, кого хочешь спроси :(

> Вот смотри, дяде выгодно давать гарантию 6 месяцев. И пофиг, что реально карты работают годами. Но ты же не пойдешь через год доказывать, что карта на самом деле может работать гораздо дольше, и что дядя оборзел, давая всего год гарантии? ГАРАНТИЯ --- 6 МЕСЯЦЕВ, И ПЛЕВАТЬ, ЧТО ОНА МОЖЕТ РАБОТАТЬ И ДОЛЬШЕ

Я с этим и не спорю. Но ты же не станешь спорить, что дядя оборзел и зажрался, что с теми же затратами он мог дать гарантию на год? Что дядя тебя просто кинул? И что ты можешь кинуть его в ответ (если сможешь).

>> Касательно gigabit ethernet driver userspace тестов - он _не_ обрабатывает высокоуровневые протоколы (например как ip), в то время как ядерный драйвер передает данные в сетевой стек

>??? Цитата из статьи: "We did not want to start comparing IP stacks, so none of these tests actually use higher level protocols." Так что (по их словам) никаких контрольных сумм и обработки потока не делали ни ядерный драйвер, ни юзерспейсный.

Конечно, т.к. сокета не было - данные забирались (кстати, еще вопрос через napi или нет, судя по слома 100usec holdoff NAPI выключен) в стек, где отбрасывались - как таковой обработки протоколов нет, но начальный этап есть (в ядерном случае).

>> IDE userspace driver тест - копирование 64мб с диска - тест некорректный, т.к. оба драйвера и userspace, и kernelspace уперлись в потолок производительности жесткого диска, но даже при этом видно, что kernelspace масштабируется линейно при росте буфера, а userspace начинает загибаться

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

Ничего себе близки - на 4кб буфере разница в 7 МБ/сек, на 8кб буфере - около 10 МБ/сек, CPU usage еще бОльшая разница.

Некорректность в том, что если бы они сделали это с RAID, то kernelspace на 2х дисках показал бы 80 МБ/сек, а userspace - около 50.

>ИМХО, проблема с shared прерываниями - более серьезная..

>Но в общем - очень даже многообещающе. Вылизать (и решить проблему с shared прерываниями) - и будет нам счастье.

Сильно сомневаюсь...

>tailgunner (*) (14.12.2006 21:39:02)

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

Да. И благодаря этим товарищам у вас есть вообще что-то кроме закрытого кода. Который _ГОВНО_.

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

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

> и когда товарищ Energizer, которого я очень уважаю за адекватность

Убил. И съел.

2MYMUR * (*) (14.12.2006 21:56:06) :

Опередил, млин, я как раз перелистывал в поисках этого куска :)

> ... что-то кроме закрытого кода. Который _ГОВНО_.

Мда. Доводы в стиле Майкрософт, которая расказывает что всякая перацкая венда глючит страшно. Типа, если я пишу программу, которая честно выполняет свои функции и не падает - у меня код нормальный. Но как только я его решаю закрыть - он сразу превращается в _ГОВНО_, без усилий с моей стороны :)

>> page_cache_get/release - это увеличение/уменьшение (с освобождением) reference counter.

>Про page_cache_get я ничего не говорил. Я упоминал get_user_pages.

get_user_pages() лочит страницы userspace - это факт (вызывая lock_page()), но его производительность выглядик как функция квадратного корня (в лучшем случае) с ростом размера памяти, что неприемлимо - у того же автора есть исследование на эту тему в том же топике, насколько я помню.

>>>page_cache_release - это совсем не free. Она unpin страницу кэша страниц, делая эту страницу доступной для page out. Сама она, конечно, page fault не вызывает.

>>Что? Ядро такой OOPS отпишеь, когда узнает, что pinned page была передана в page_cache_release() при refcnt == 1

>К моему стыду, я не знаю, какой там будет reference counter. Скорее всего, get_user_pages увеличит его на 1 (до 2 ;)), драйвер выполнит В/В, а потом page_cache_release уменьшит его до 1, сделав страницу доступной для paging.

Если она при этом залочена, то случится OOPS. Paging не имеет прямого отношения к reference counter, в первую очередь страница должна быть не залочена.

>> ядерный драйвер не должен их копировать, используюя copy*user(), ему достаточно сделать dma в страницу из vfs cache, а userspace драйвер их оттуда еще и копировать будет, либо будет лочить весь vfs cache

Насколько я понял из статьи, они реализовали специальный системный вызов - usr_pci_map, который просто обертка pci_map_sg, так что копировать им не придется - драйвер зафиксирует страницы в памяти, и начнет DMA прямо в них.

Драйвер их залочит get_user_page() или аналогом? Низкая производительность (они конечно это время не учитывали). Если время локов не учитывать, то им еще нужно реализовать vfs cache в userspace, или отдавать страницы назад в ядро - а именно это и придется делать, т.к. все userspace программы пересобирать для использования нового API для userspace VFS cache никто не станет. А если они будут использовать залоченные страницы для vfs cache, то очень быстро закончится память, либо кэш будт неэффективным при невозможности расти и сужаться, а расти и сужаться он не может, т.к. userspace драйвер об этом не знает.

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

>tailgunner (*) (14.12.2006 21:55:48)

> Если рынок затоварен дорогими картами, и их просто не берут - он напишет на нормальной работоспособной карте entry-level, заблокирует ей пару конвейеров и продаст

Ага, так и представляю себе - представители нвидии ходят по магазинам и перешивают биос на половине hi-end видюх... :)))

Головой совсем не пользуешься? Все эти разгоны и открытие конвееров возможны по одной единственной причине - цена и "покупаемость" карт распределяется несколько иначе, чем процент выхода годных чипов. Поэтому часть более дорогих чипов тем или иным способом урезают чтобы продать как более дешёвые. Хорошо, не нравится вам блокировка в биосе или в драйверах, будут за чуть большие деньги урезать чипы ЖЕЛЕЗНО, например перерезая что-то на самом чипе перед его упаковкой и установкой на плату. Тогда вы тоже петь будете что производители вас обманывают? Ну так вперёд громить AMD и Intel за то что те вероломно впаривают людям семпроны и селероны, не говоря что в части из них можно открыть половину кэша и второе ядро... У AMD подобное было, когда они были совсем нищие и пытались срубить деньги хотя бы на оверклокерах. Сейчас поднялись и продавать младшие процы с раскрываемым кэшем и множителем уже конечно не будут.

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

>Я с этим и не спорю. Но ты же не станешь спорить, что дядя оборзел и зажрался, что с теми же затратами он мог дать гарантию на год?

Блин, "если ты такой уиный --- то почему не богатый?" =)))

Не нравится --- не покупай.

Как разработчик коммерческого ПО для ядра могу предположить, что ничего хорошего из этой затеи не выйдет. Открывать код, обложенный патентами, естественно, никто не станет. И перетаскивать в userspace, теряя производительность и управляемость - тоже плохая затея.

> И вообще, куда доводит фанатичное следование идеологии (когда она начинает быть не двигателем, а целью) наглядно показывала история не раз и не два на очень разных примерах.

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

боюсь, что дома для Linux 2.6.x aka RHEL4 в VMware я не могу провести достаточно объективные тесты: результаты теста IPC на Intel Core 2 Duo 6400 с обеими ядрами on между сериями разнятся от полутора до двух-трех раз:

foo@localhost: ./pipetest 10000000
Num calls 10000000
Start
Terminate
Time 13082 msec speed 1528000 calls/sec

foo@localhost: ./pipetest 10000000
Num calls 10000000
Start
Terminate
Terminate
Time 51791 msec speed 386000 calls/sec
Time 51791 msec speed 386000 calls/sec

foo@localhost: ./pipetest 10000000
Num calls 10000000
Start
Terminate
Time 16730 msec speed 1194000 calls/sec

foo@localhost: ./pipetest 10000000
Num calls 10000000
Start
Terminate
Time 35831 msec speed 558000 calls/sec

это явно неприемлимо. подозреваю, что тут уже виновата VMware в плане времени и тесты явно Linux некорректны. предлагаю оставить challenge до завтра, когда у меня будет доступ к живому железу.

ps: для QNX4 примерно то-же самое на одном ядре дает:

$ uname -a
QNX 1 O 425 PCI 32

$sin ver
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25O Aug 19 2002
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/sbin/Fsys Fsys32 4.24Y Apr 23 2002
/sbin/Fsys.atapi atapi 4.25G Apr 08 2005
//1/sbin/Net Net 4.25E Apr 24 2002
//1/sbin/Net.ether2100 Net.ether210 4.24G Feb 17 2000
//1/sbin/Dev Dev32 4.23G Oct 04 1996
//1/sbin/Dev.pty Dev32.pty 4.23G Oct 04 1996
//1/sbin/Dev.ansi Dev32.ansi 4.23H Nov 21 1996
//1/usr/ucb/Tcpip Tcpip 5.00C Feb 12 2003

./srrtest 10000000
Start
Num cycles 10000000
Child enter
Child done
Start
Num cycles 10000000
Parent enter
Parent done
Time 136211 msec speed 219000 calls/sec
Terminate

завтра посмотрим что и как :)

// wbr

Пожалуй, соглашусь с мнением Линуса по этому поводу.. Преждевременный, а то и вовсе излишний шаг..

dmitry@darkstar:~/cuptest$ ./syscall_test 100000

num: 100000, diff: 34728, speed: 0.347280.

dmitry@darkstar:~/cuptest$ ./syscall_test 100000

num: 100000, diff: 35146, speed: 0.351460.

dmitry@darkstar:~/cuptest$ ./syscall_test 100000

num: 100000, diff: 34697, speed: 0.346970.

dmitry@darkstar:~/cuptest$ cat /proc/cpuinfo

processor : 0

vendor_id : AuthenticAMD

cpu family : 15

model : 4

model name : AMD Athlon(tm) 64 Processor 2800+

stepping : 10

cpu MHz : 1811.572

cache size : 512 KB

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 1

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow ts fid vid ttp

bogomips : 3625.36

> Разрабы драйверов nvidia писали, что у них есть купленные у десятка 3х фирм технологии, которые по договору открывать наружу нельзя

Значит nVidia является тем исключением. По крайней мере я не вижу причин подозревать Theo в откровенной лжи. Но это далеко не обязательно общая ситуация.

s/cuptest/cputest/g

> А в каком месте драйверы nvidia нарушают GPL?

Для точного ответа надо исследовать модуль. Затем сверить с GPL FAQ. Там разъясняется, при каких случаях программу можно считать единой, даже, если общение происходит через IPC.

Если окажется, что nVidia ухитрилась и рыбку съесть и на лодочке покататься, то честь им и хвала.

>Я считаю, что Линус не прав, так как этим нововведением он ограничивает свободу выбора.

Ну теперь он прочитает твой пост на ЛОРе, устыдится, посыплет голову пеплом и принесет извинения мировой общественности на ближайшем заседании ООН :)

> Ещё раз. Допустим, у вас спецификация есть. Так написано, что этому чипу положено работать на 200 Mhz, допустим. Вы его гоните. Или написано, что у него 6 конвееров. Вы включате заблокированные. И после этого считаете, что имеете право нести устройство в гарантию ? Я вас так понимаю ?

Не так. Производитель гарантирует нормальную работу на 200 Мгц и при 6 конвеерах, именно столько я и буду использовать, если ожидаю получить гарантированный результат. Но документация должна позволять использовать все предусмотренные изготовителем возможности, не более и не менее.

Только вот для некоторых функций может оказаться, что они совершенно искусственно урезаны, каковое урезание не имеет под собой абсолютно никаких технических оснований, навроде ограничения на запуск не более трёх задач в Windows Starter Edition. Или разницы между серверной и пользовательской версией винды.

> Не так. Производитель гарантирует нормальную работу на 200 Мгц и при 6 конвеерах, именно столько я и буду использовать, если ожидаю получить гарантированный результат. Но документация должна позволять использовать все предусмотренные изготовителем возможности, не более и не менее.

Представьте что оно зарезано в железе и уймитесь уже. Т.к. если всё это пойдёт на полном серьёзе, так оно и будет, причём за ваши же деньги. Вам хочется ВООБЩЕ остаться без разгона и разблокированных конвееров? Нвидия халяву с квадрой уже прикрыла по этой же причине, на очереди всё остальное.

> Те, кто работает с зеркальными фотоаппаратами видят это явление в полной красе. Плёночная 35-мм техника давно достигла своего апогея и теперь загнивает - производители отказываются от её производства.

Ну я бы не сказал. Во всяком случае ни Nikon, ни Canon ещё не отказались от их производства, хотя и сократили модельный ряд, оставив только дешёвые и дорогие модели, хотя опять же как посмотреть, топовый никоновский F5 стоит примерно столько же, сколько совсем не топовый D70 или D80. Правда FM2 всё равно останется легендой :) А вот с выбором плёнки и возможностью её нормально проявить и отпечатать стало сильно хуже.

> Именно из-за того, что никто ничего не урезал - все гнались за качеством. То же самое может произойти и с ПО - сначала быстрый рывок вперед, а потом медленный но верный распад и загнивание.

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

А вот проприетарно-виндовый как бы и в самом деле уже не начал разлагаться, ЕГАИС -- это только самый вопиющий пример, но и знакомство с творчеством системных интеграторов нередко оставляет недоумение. Конкретно у меня оставил недоумение кое-какой заказной софт, разработанный сименсом: в принципе функционально работает хорошо, но хронически глючит.

> Лицензия на ядро - GPL с исключением для закрытых двоичных модулей.

И где это исключение? Смотрю исходники 2.6.17. COPYING. Стандартная GPL, с примечанием Торвальдса, о том, что легально вызывать язро через syscall и для не-GPL кода, а так же, что к ядру применяется только лицензия v2.

Поискал в документации - тоже не нашёл. Может плохо искал?

Всё, что я нашёл - это файл rpm'ке (!) COPYING.modules, в котором выдержки из переписке Торвальдса по этому вопросу. Там он всего лишь объясняет свою позицию (модуль, который просто висит в адресном пространстве ядра, для доступа к железу, но не использует ядра - не является производной работой и может иметь на GPL лицензию). Но это лишь его imho, не соответсвущее GPL. Мы же не будем молиться на Торвальдса?

Если я правильно помню :) , отданное под GPL становится собственостью сообщества. Авторов, пользователей... Всех, кто имеет законную копию. Соответсвенно если сообщество вцелом больше не захочет мириться с не-GPL модулями, то они уйдут. Потому что никаких поправок к лицензии не существует. Фактически, это и сейчас нарушение закона. Но все закрывают глаза. И чем дальше, тем больше народу не хочет закрывать глаза. Соответсвенно, даже если сейчас инициатива не пройдёт, вопрос о выкидывании не-GPL модулей не звучит, как - "надо"/"не надо", "если"... Он звучит, как "когда".

> Energizer, которого я очень уважаю за адекватность

Вы у врача давно были? Сходите... :)

> MYMUR (*) (14.12.2006 21:56:06)

Да, да, да... Нам знаком этот отрывок. Есть только одно но. С того самого момента, как было скачано первое ядро под GPL, с того самого момента, как он принял первый патч - это уже не только его программа. Сейчас с ним просто пытаются договориться. Потом - оставят впокое. На совсем. Благо, git позволяет это легко и непринуждённо. :)

P.S. MYMUR, подумайте сами. Ядро пишет далеко не один Линус. Но получается, что ему другие авторы не могут навязывать политику лицензирования. А он другим - может?

>Благо, git позволяет это легко и непринуждённо. :)

И что дальше? Гордые и неприступные пингвины останутся полностью без поддержки коммерческого производителя? Или вы полагаете, что Торвальдс со своей позицией останется вдруг в гордом одиночестве?

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

> Т.о. мне производитель автомобиля может послать с гарантийной поломкой, если я залью бензин/масло "не от производителя"?

Вправе послать, если в правилах эксплуатации указана не та марка, которой вы заправлялись. Или вы считаете, что если в правилах написано заправлять 92-м бензином , а вы решили сэкономить и залили 76, то производитель вам что-то должен?

Линус как всегда прав, имхо для десктопа на сегодняшний день нельзя выложить все технологии в сырцах, нужен мост между закрытыми и открытыми технологиями, чего боятся собственно опенсоурсники в лице Столман?
Я думаю что, они боятся потерять контроль над софтом, имхо если Майкрософт начнёт выпускать проги на базе таких программ , то естественно они об этом никому не будут говорить.

<Главная цель акции - заставить разработчиков закрытых драйверов вынести основную функциональность драйвера в виде пользовательского процесса (userspace), оставив в виде модуля ядра только минимальный код.>
Что имхо вызывет очередной форк ядра и плюс невозможность стандартизации Линукса как нормального десктопа. Хех, не нужно долго ходить за примерами когда команда Xfree перешла на другую лицензию, все дружно стали продвигать Xorg.
И не нужно нам тут рассказывать про идеалогию, мол всё должно быть free и никаких лицензий, другое дело что юзеры только от этого страдают.
Имхо, пришло время когда Линус должен окончательно решить , что развития ядра нужно разделить на несколько ветвей desktop , server, embeded, development.
Desktop будет состоять по умолчание из GPL программ и частично из closed source модулей (вспомните тот же самые нвидиа драйвер)
Server был бы полностью free - open source.
development это ветвь ядра состояла бы только из эксперементальных и новых технолигий , т.е. только open source модули и код.
embeded: имхо тоже должен быть open source

Каким бы образом развивался desktop версия ядра?
Естественно медленно, но учитывая тот факт что желязники имели бы полную поддержку со стороны коммерчиских дистров и плюс комьюнити им было бы гораздго легче создавать дрова под Линкус.
Так, что GPL и closed source имеют право на жизнь, и если есть возможность создания моста между ними то это только нужно привествовать, так как ещё неизвестно чем это для closed source обернётся. :)

> Потому, что спеки не откроют и нормального драйвера не напишут. Или напишут когда он будет уже мало актуален. Я помню 1999 год когда дров небыло вообще ни для чего и обратно не хочу.

Чего пугаться я не понимаю. В конце-концов, право модифицировать ядро и выкинуть запрет на не GPL модули никто не отменяет, более того, такие дистростроители как RedHat, Novell и Mandriva, скорее всего так и будут делать, если ограничение начнёт сильно доставать.

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

> Разрабы драйверов nvidia писали, что у них есть купленные у десятка 3х фирм технологии, которые по договору открывать наружу нельзя, поэтому они бы и рады, да не могут, потому как их засудят.

Организовали бы что-ли утечку информации ;-))

> num: 1000000, diff: 290732, speed: 0.290732. > ... > 0.2 микросекунд. с каких это пор 0.29 принято округлять до 0.2 o_0

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

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

Ну-ну... Мечтайте дальше. Время само покажет что есть где...

> Ты неправ. Вот выдержка из взятого наобум гарантийного талона: "Гарантия не распространяется на следующие элементы и поврежднения: 1)бла-бла-бла... ...n) при наличии насанкционированного вскрытия, ремонта, попыток внесения изменений в конструкцию или программноге обеспечение..."

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

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

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

Ничего подобного. Линус прав. Вот поэтому РМСа сравнивают с комунизмом - основная фишка в свободе - это возможность ее выбрать. Линус и говорит о том что чем они тогда лучше RIAA если заганяют штыками в свое видение мира? Никакой радикальный фундаментализм не приносит ничего хорошего. Линус прав - люди пишущие бинарные драйвера, которые не являются derived work _ничего не брали_ из наработок GPL. ЗАставлять их что-то делать силой или ставя в безвыходную ситуацию на рынке - это ничем не лучше того что делает RIAA - эти люди OSS ничего не должны. Это покушение на право этих людей выбирать свой собственный путь. Это _не_ свободно и _не_ хорошо.

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

Расскажи это Trolltech который дал Qt и в общем-то KDE. Qt существует потому что продается проприетарным разработчикам.

> развития ядра нужно разделить на несколько ветвей desktop ,server, embeded, development.

Ничего не напоминает?

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

> Я думаю что, они боятся потерять контроль над софтом, имхо если Майкрософт начнёт выпускать проги на базе таких программ , то естественно они об этом никому не будут говорить.

ИМХО закрытый драйвер в ядре эквивалентен дыре в безопасности. Что, например, мешает драйверам nvidia передавать информацию о пользователе компании, например, для сбора статистики? Кто сказал, что при таком раскладе та же nvidia не сможет заблокировать всю защиту ядра? И получится, что не ядро управляет системой, а _один_ проприетарный драйвер.