проприетарные драйвера хорошо, но открытые еще лучше. Жаль из-за специфики разработки nouveau его до сих пор нет под NetBSD и OpenBSD, а под FreeBSD на грани прекращения поддержки.

Кстати, nvidia-блоб до сих пор использует GIANT-блокировку во фре. И MSI там как-то странно работает (или не работает, ибо irq16) по сравнению с nouveau.

АПВОВНВ? :)

Товарищи бздуны уникальные зверюшки.

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

Если внимательно поискать посты изена, с нахваливанием вантуза всех мастей, то начинаешь задаваться вопросом: «А зачем им БСД?». Но при этом упорно доказывают, что сидят на венде, только с работы. Но, потом внезапно оказыаются рано утром часа эдак в 2, сидит все время с winnt 5.1. Но при этом параллельно не забывает обосрать линупс. Изенушка, в 2 часа утра, в выходные, сидеть на работе, какая к ней любовь.

Вот феерические посты изена http://www.linux.org.ru/view-message.jsp?msgid=4256535 и, ВНЕЗАПНО, вменяемый БСДшник в треде slovazap, что является большой редкостью в наши дни.

> Товарищи бздуны уникальные зверюшки.

Видищь ли, у них комплекс. Согласно традиции, специалист должен проводить в своей основной среде не менее 50% времени, иначе это не специалист, поскольку иначе решить мало-мальски серьезную проблему он не сможет - он сначала не поймет, что пробелма возникла, а потом будет поздно. Отсюда и комплексы большинства БЗДунов - они сами не считаютс специалистами, и это вызывает у них в душе когнитивный диссонанс :-)

нихт копенгаген

> Какие линукс фичи?????

Рекомендуется к изучению http://wiki.freebsd.org/NvidiaFeatureRequests , особенно последний пункт в табличке ;)

nnz, пожалуй, и я со своей слако-гентушной (хотя сейчас пишу из-под винды, т.к. предложили потестировать «AION») колокольни, приложу пару аргументов.

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

Рискну напомнить буквально «вчерашнее» отношение FreeBSD'шников к Линукс — «пионэрское поделие», «тимуровская разработка», прочие бла-бла-бла того же рода... Причём. На одном из достославных сайтиков (про фряху, блоги тогда были не в моде) видел две статьи. Одна была про то, что де «линукс система без будущего», а вторая описывала... применение brandelf. Во FreeBSD. Но позвольте — мне неведом утиль для аналогичных действий, но с точностью до наоборот. Т.е., я даже никогда не рассматривал перенос бинарей из фряхи в линукс, хотя с фряхой был дружен с версии 1.0, со слакой — я версии ядра 0.99! Таким образом, здесь классическая ситуация — «за что боролись, на то и напоролись». И нефиг теперь, опосля стольких лет срача плакаться про злых линуксоидов.

Это был «раз». А теперь «два». Сравнивая путь фряхи и линукса, сегодня, после использования систем с 1994г., я могу заметить, что подход фряхофилов, с их «десктоп под виндой, а вот „боевой сервер“ фряха, этточно», порочен на корню. Линуксоид средней руки, как правило работает в гомогенной среде. Т.е., и сервер и декстоп это, как правило (не всегда, оговорюсь, но зачастую), один и тот же Линукс. В разных заточках и разных вариантах, но не столь суть. Это _ОДНА_ система, с _ОДНИМИ_И_ТЕМИ_ЖЕ_ проблемами и средствами их решения. В результате пусть даже средней руки линуксоид _ПОНИМАЕТ_ систему лучше и глубже, чем понтоватый фряхофил, у коего за душой окромя понтов нет ровным счётом ничего. Знания о том, ак из коллекции понтов поставить что-либо и прописать конфиг? Да ну на хер! Можно ли это сравнивать с пусть даже угрёбищных Qt/KDE программированием под Linux? Не думаю... Кстати, снимаю вопли про Qt/KDE — сам GTK/GNOME'овец. И уже давно. С версии 1.4.

Ну и «три». Вопрос к фряховодам. А чем, собственно, «фряхо-движение» обогатило «Мир»? Ну с OpenBSD понятно — там мужии по всячесой секьюрности убиваются. Но вы-то что нам всем дали? В вянду портировали сте TCP/IP, скоммуниздив его из фряхи? Ну и хрен бы с ним... В Линукс стек свой. Чего дальше? Ни-че-го. Ноль.

В итоге. Ре-бя-та... То, что сейчас все, кому не лень, метелят фряховодов, вполне обоснованная ситуация. Вы сами это выпросили. И, вдобавок, метелят вполне имея на это право. Уж простите великодушно — скромнее надо было быть в своё время. Сейчас у вас получается только огребать. Поколение Убунту подросло знаете ли... С чем я всех и поздравляю.

Интересно, зачем такому прожженному и упертому линуксоеду как нетудаши нужен вантуз? И не из под него ли он тут троллит?

> Если хорошо посмотреть скорость развития linux kernel - то можно легко заметить что скорость разработки принесена в жертву качеству - что хорошо иллюстрирует количество уязвимостей в linux kernel. Как по мне лучше будет медленная разработка в FreeBSD чем базар и прыжки во все стороны в Linux.

Если я не ошибаюсь, то «эволюция» как процесс, весьма, знаете ли, хаотична. Динозавры то же вымирали медленно. А вот более «быстрые» существа живут.

Вот такой он.. стабильный линукс - с детскими ошибками :-)

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

API no-sense рулит, но не для сторонних разработчиков - которые в результате начинают думать о сворачивании поддержки linux и поглядывают в сторону чего нить боле стабильного.

Дайте угадаю... Microsoft??? 8-| С их едва-едва описанным API, который принесли в жертву новой и блестящей (и, ясен хер, до офигения инновационной разработке?). Оно понятно. Ведь в M$ API описан на все 100% и ни фига нет недокументированных возможностей. Про фряху здесь и собаки не лают, ибо работать с фряхой на десктопе получится, но с таким гимором, что ну его к Богу в Рай. А содержать _ДВЕ_ системы слишком накладно с точки зрения «total cost of ownership». И ни один вменяемый руководятел на это в трезвом уме и при здравой тёще, просто не пойдёт. Т.к., цена будет куда как выше, нежели с «нестабильным» по Вашему мнению Линуксом. С другой стороны, может, Вам hardened gentoo для себя открыть, не поможет? :)

> Если я не ошибаюсь, то «эволюция» как процесс, весьма, знаете ли, хаотична. Динозавры то же вымирали медленно. А вот более «быстрые» существа живут.

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

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

Один отправлен, второй числится в багзиле RedHat как исправленый референс на его исследование: http://lists.gforge.inria.fr/pipermail/open-mx-devel/2009-March/000165.html А если хорошо посмотреть как оно фиксилось (в redhat bugzilla) то фиксили что угодно кроме MM кода. Один из instance данного бага - фиксили через уменьшение max LVM devices - тогда скорость аллокации новых девайсов не давала условия для воспроизведения этой ситуации. Вот и говорю - смешные линуксоиды.. А проблемы с поддержкой всей гаммы ядре при API no-sence мне рассказывать не надо - я этого наелся за 3 года. Один переход от vm->nopage() с unlocked page, к vm->fault() с locked page и не обходимость поддерживать оба варианта, и разруливать все возможные проблемы с прохождением по приложению лоченой страницы - весьма порадовала.

Дайте угадаю... Microsoft??? 8-| С их едва-едва описанным API,

Что вы так возбуждаетесь от слова стабильный API? понимаете что занестабильность Linux и не любят - но как еж жрете этот кактус? Можно просто поглядеть сколько воплей стоит пока напишут обновления дров под nvidia / ati - после выхода нового ядра. С другой стороны планеты - 2.4 vs 2.5 ядра, 2.4 стабильный код - 2.5 для девелоперов и любителей новизны который потом превратился в 2.6. Но поддерживать свой код внутри внути 2.4 было в разы проще. Или взять BSD системы - которые сознательно тратят ресурсы что бы для сторонних разработчиков приходилось менять как можно меньше внутри одной ветки. Или солярис с такой же политикой... Странные люди линуксоиды... Ну так можете продолжать жрать свой кактус ;-)

> А содержать _ДВЕ_ системы слишком накладно с точки зрения «total cost of ownership». И ни один вменяемый руководятел на это в трезвом уме и при здравой тёще, просто не пойдёт. Т.к., цена будет куда как выше, нежели с «нестабильным» по Вашему мнению Линуксом.

Цена поддержки сложного приложения (~20M кода) который работает со практически всеми подсистемая ядра (VFS, MM, block device, FS, Network - включая RDMA transfer).
и должно поддерживать ядра - начиная с SLES9 (2.6.5) включая последний SLES11(2.6.27) и ванилу (2.6.30 к примеру) - это примерно две-три недели работы программиста, на изучения изменений в каждом новом ядре и адоптации кода к этим изменениям. Типовой объем патча в этом случае - от 50кб до 300кб - включая autoconf tests и необходимые заплаты и переписывание кода.
как это было в случае splice_read vs send_file, или vm->nopage vs vm->pfn() vs vm->fault().
Интересно какой вменяемый руководитель будет считать что регулярное внесение такого объема изменений благотворно скажется на стабильности продукта?
А стоимость работы программистов по портированию кода на новое ядрышко?
А затраты на поддержание стабильной ветки?
Нет уж.. total cost of ownership в случае Linux получается запредельным.

> Интересно, зачем такому прожженному и упертому линуксоеду как нетудаши нужен вантуз?

Не вижу смысла отвечать анонимусам.

Школота, такая школота. Назови имя используемого тобой дистрибутива, мальчик.

> total cost of ownership в случае Linux получается запредельным.

И почему же вы тогда не забросите линукс и не уйдете на что-то стабильное?
Если поддержка продукта нерентабельна - закрывайте ее или меняйте политику (мы поддерживаем только RHEL/SLES/чего там еще таких-то версий, и все).
Если поддержка рентабельна - не надо ныть про то, что приходится вкладываться чтобы подстричь бабло.

For those who don`t know

http://wiki.freebsd.org/NvidiaFeatureRequests

> Сравнивая путь фряхи и линукса, сегодня, после использования систем с 1994г., я могу заметить, что подход фряхофилов, с их «десктоп под виндой, а вот „боевой сервер“ фряха, этточно».
Вот уж не надо. Фряха сейчас шоколадно чувствует себя на десктопе.
Мало того, не мало был расстроен, что X + KDE/GNOME идентично ведут себя и чувствуют, что под фряхой, что под линуксом. При этом, объясните мне, почему у мну Фряха из-коробке производительней себя ведёт, нежели иной дистр доброуважаемого Линукса?
Я пользуюсь компилами на Фри под тарджет архитектуру (что пошустрее generic билдов), но тогда некорректно сравнивать с дистрами которые основаны на RPM, посему и пример про «из-коробки».

amd64 на дектопе не понятно. Over 4GB памяти усреднённому разработчику вроде как не к чему. Десктоп юзверу и подавно.
Однако новость приятная, архитектуры пусть будут все поддержаны.

> подход фряхофилов, с их «десктоп под виндой, а вот „боевой сервер“ фряха, этточно», порочен на корню

Как всегда! Придет недовольный линуксоед и начнет трындеть о венде. А за пазухой у него часто VBox (в котором установлена венда) или wine (для запуска вендовых приложений)[1]. Стоит ему сказать, что опенсурс не ограничивается пингвинами, так идеалы сразу отправляются в утиль и вспоминаются бинарные побрякушки (невидия, оракля, лолус, варваря, опера, флеш, етц.).

Чтоб тебя Столлман покарал за пропаганду^Wупоминание венды в суе на опенсорсных порталах.

[1] не вспоминая самый популярный вариант - дуалбут linux/win

>> Если хорошо посмотреть скорость развития linux kernel - то можно легко заметить что скорость разработки принесена в жертву качеству - что хорошо иллюстрирует количество уязвимостей в linux kernel. Как по мне лучше будет медленная разработка в FreeBSD чем базар и прыжки во все стороны в Linux.

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

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

> Фряха сейчас шоколадно чувствует себя на десктопе.

Судя по тому, что я вижу в подпеси к твоему посту, ты сам в это не веришь :-)

> а еще версия линукса 2.6, а винда уже аж 7. И 7 > 2.6, соответственно Винда круче в 2.69 раз!

К.О. как бы намекает - не 7, а 6.1

> iZEN> Теперь можно спокойно покупать Widescreen-мониторы и наслаждаться Full HD в полном экране на фоне процесса сборки портов.

Нафига для консоли Full HD?

Нафига для putty.exe Full HD?

fixed

> Over 4GB памяти усреднённому разработчику вроде как не к чему. Десктоп юзверу и подавно.

мультимедия приложения кушаеют память ого-го. Остальное уходит на кеш (nfs, ufs/zfs, prefetch, etc.)

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

Сделай апгрейд мозга - не думай однозадачно!

Ну, на столе, пожалуй, и i386 достаточно. Ну если только надо что-то программировать/проверять под amd64, а на сервер его исходники класть не хочется, тогда может быть, но это достаточно частный случай. Так что драйвер под amd64 может не особо и нужен. С другой стороны, так глядишь, они и cuda под FreeBSD подопрут, а это уже и на сервере очень интересно становится.

\telepat_mode{ win7 + ff? }

> Судя по тому, что я вижу в подпеси к твоему посту, ты сам в это не веришь :-)
/me знал, щто это будет. :)
Таки да, где-то перекрутил ручками, слетели русские шрифты, а работа не стоит на месте. Это в разных *nix системах бывает.

P.S. Да и не до конца докопал: M$ Eхchange со всеми плюшками из под Linux/FreeBSD. + ISA сервер с NTLM аутентификацией в компании (рабочая почта/календари + прокси). Приходится лазить в оффтопик. Но это уж независет *BSDли, Linux ли. (четаю маны)

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

проект и так в процессе перехода с Linux. К сожалению проект слишком большой что бы это сделать быстро, и написан не слишком портабельно. Но вы правы - процес идет и Linux становится прошлым днем. Никому не интересной поделкой.
Хотя сейчас это очень известный проект - которым linux world пытается гордиться «а вот у нас есть - а у других нету» - ну ну.. гордитесь дальше.

Если поддержка продукта нерентабельна - закрывайте ее или меняйте политику (мы поддерживаем только RHEL/SLES/чего там еще таких-то версий, и все).

Вы сами поняли что сказали? Видимо нет - иначе не говорили бы такую глупость ;-)
Затраты на прыжек SLES9->SLES10->SLES11 - это переписывание порядка 20-30% кода. Фигня не правда ли? Отладить такой кусок кода - это нечто unreal, поэтому приходится размазывать такие изменения портированием на каждое новое ванильное ядро. Хотя что я тут рассказываю азы разработки приложений.. э
Это же все равно воспримут как нытье.

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

Где вы видели нытье? вам указали на конкретные проблемы - конкретного проекта связаные с тем что в 2.6 ядре стали часто ломать API.
Указали проблемы с обеспечением качества данного продукта.
Собственно в этом всем весь Linux world - когда им указываешь на проблемы - это называется нытьем, или иначе «потребности в колбасе нет» - ну ну.. суйте дальше голову в песок - только не разбейте ее о каменную плиту.

P.S. Да и не до конца докопал: M$ Eхchange со всеми плюшками из под Linux/FreeBSD. + ISA сервер с NTLM аутентификацией в компании (рабочая почта/календари + прокси). Приходится лазить в оффтопик. Но это уж независет *BSDли, Linux ли. (четаю маны)

fxd. не по теме.

>Хотя сейчас это очень известный проект - которым linux world пытается гордиться «а вот у нас есть - а у других нету» - ну ну.. гордитесь дальше.

Не томи, все равно тебя никто не запалит. Что за проект такой?

> независет, четаю

OMG

>> Хотя сейчас это очень известный проект - которым linux world пытается гордиться «а вот у нас есть - а у других нету» - ну ну.. гордитесь дальше.

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

Не очень-то доверяй подписям =) user-agent это такая нестабильная вещь ;) Особенно под файерфоксом, снабженным каким-нибудь user-agent switcher'ом

> независет, четаю

OMG

Граммар-наци, простите?

> К сожалению проект слишком большой что бы это сделать быстро, и написан не слишком портабельно

Сами виноваты. Чем менее портабелен код, тем более он гвоздями прибит к отдельно взятой платформе, тем больше надо пилить при изменении в платформе.

Хотя сейчас это очень известный проект

Название в студию.

> Не очень-то доверяй подписям =) user-agent это такая нестабильная вещь ;)

Зато история твоих постов куда более стабильная вещь...

>> Не очень-то доверяй подписям =) user-agent это такая нестабильная вещь ;)

Зато история твоих постов куда более стабильная вещь...

Это точно! Чего никак нельзя сказать о тебе =)

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

Да-да, благородный дон. Зачем вам на рабочей станции >4Gb на процесс?

PC GAMESS?

> Причем тут эволюция и хреновое качество кода? за которым уже никто не может уследить (см. интервью Торвальда и различные высказывания Мортона). Но ведь это же Linux позиционируется как стабильная система, а никто-то там еще?

При том, что:

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

Всего два варианта — либо изменения приживаются, либо они отмирают. Но в любом случае это процесс не безболезненный и требующий ряда проб и ошибок. Отсюда, как следствие, требование к защите не столько ядра, до коего надо ещё и дорубиться — пинком здесь двери не открываются, а к защите программного обеспечения, работающего в юзерспейс и представляющего основную угрозу системе. А оно одно и то же что для фряхи, что для линукс. Так при чём здесь «стабильность ядра»? Она более чем достаточная. Если не рукоблудить безумно.

Во-вторых. А зачем в открытом продукте за чем-то «следить»??? Вот этого я вообще не понимаю. Есть описаные чётко и явно API. Тех же подсистем ядра (как пример). Если Вы или кто-то иной вносите свои изменения и публикуете их, то я открою Вам тайну... Оно всё должно работать нормально. И стабильно. Если нет, значит что-то где-то крайне сильно накосячено. Уж будьте добры сами поправить. Вообще-то, «свобода» это не «право» ездить на электричке без билета. Это право выбирать тот или иной путь (транспорт). Надеюсь, аналогия не сильно крива и достаточно понятна? Поставить за спиной у каждого девелопера по Торвальдсу? А зачем? Может, за спиной у каждого мента (или манагера) поставить по Медведеву/Путину? Чтоб «воспитывали» — не воруй, работай честно... Это явления одного порядка. Порядка готовности к свободе. Не готовы? Ну, сталбыть, не судьба... :)

Ксати, думаю не совру, если скажу что есть даже правила записи кода для модулей ядра — например, «<Tab> = 8 символов», «не более пяти уровней вложенности» и т.д. и т.п. Если девелопер следует _правилам_, а не придумывает новые (и свои, персональные), то всё ровно. Если нет, то ССЗБ.

Один отправлен, второй числится в багзиле RedHat как исправленый референс на его исследование:

Gut. Das ist gut...

А если хорошо посмотреть как оно фиксилось (в redhat bugzilla) то фиксили что угодно кроме MM кода. Один из instance данного бага - фиксили через уменьшение max LVM devices - тогда скорость аллокации новых девайсов не давала условия для воспроизведения этой ситуации. Вот и говорю - смешные линуксоиды..

В остальном (из данной части Вашего постинга), если есть проблемы, то с ними борются. Как именно? Ну, наверное так, как посчитали нужным. Это правильно, Вы не находите? В противном случае ожидаются именно Ваши предложения по коду. Не здесь. Предложите сообществу _свой_ вариант решения проблемы. Либо тихо и молча «переносите»... тяготы и лишения. :))))

Правда, можете поискать ещё варианты... Но... кхмм... Я не отговариваю — дело сугубо Ваше, я почему-то не нашёл таковых.

Что вы так возбуждаетесь от слова стабильный API?

Да я не возбуждаюсь... Впрочем... Впрочем, это я соврал. Я ХОЧУ СТАБИЛЬНЫЙ API!!! :))))) Только я его не вижу. В упор. В QNX? Нет. Там не одно, так другое, плюс заточка только под определённые вещи. В Linux? Ну, сами говорите — нет, хотя, вопрос и спорен (да, в своё время, если наложить патчи Инго Молниера, то можно было получить аналог QNX, какая уж тут «стабильность»?). В винде? Ой, мама, роди меня обратно. Откуда он там? Ветром надуло, да от сырости завелось? В MSDN только гляньте — такой суповой набор из технологий просто не может быть стабильным. Ни как. Во... фряхе? Ой, и этого ненадо, ладно? В каждой избушке, знаете ли, свои погремушки. «Стабильный API» = «мёртвый и неразвивающийся API». Пока есть развитие, забудьте о стабильности.

Впрочем, nnz и коллеги тут были правы. Скоро будет Вам «стабильный» API во фряхе... Будет... :))))

> Сами виноваты. Чем менее портабелен код, тем более он гвоздями прибит к отдельно взятой платформе, тем больше надо пилить при изменении в платформе.

Дон понимает что такие вещи как обработка page fault, VFS - как в части meta data, так и в части общения с VM - по опеределению не бывают портабельными без очень не маленького overhead? Обработка page fault - не может быть стандартизирована.
Это вам не userland с POSIX, тут это чутку сложнее :)
Видимо не понимает, как и сильно заметно что у достопочтенного дона опыта в разработке серьезных проектов в ядре нету (серьезным я назову что нить большее чем написать свой драйвер блочного или сетевого устройтва, хотя бы какую нить local FS).
Так что Дон лучше бы не рассуждал о том с чем не работал, а думал о чем-то более приземленного - а то уже надоедает смешные ошибки в рассуждениях расхлебывать.

Название проекта - достопочтеный Дон может сам найти - оставлю это на домашнее задание :-)
Достаточно только подумать кому может потребоваться стопка свойств - обработка page fault, network RDMA, VFS в полном наборе, работа с блочными устройствами и журналированием (перепрыгивание jbd -> jbd2 кроме очевидных глюков с jiffes_rounding которые не позволяют вовремя комитить транзакцию и ломают этим ext4) - это переписывание неслабого куска кода.
Ну и на конец кому может потребоваться поддержка ядер с SLES9->SLES11 :)
Таких проектов меньше 5 (насколько я знаю).

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

Прежде чем учить других - стоит подумать - а вдруг это уже сделано? Подписку на lkml оставлю вам на домашнее задание.

Всего два варианта — либо изменения приживаются, либо они отмирают. Но в любом случае это процесс не безболезненный и требующий ряда проб и ошибок. Отсюда, как следствие, требование к защите не столько ядра, до коего надо ещё и дорубиться — пинком здесь двери не открываются, а к защите программного обеспечения, работающего в юзерспейс и представляющего основную угрозу системе. А оно одно и то же что для фряхи, что для линукс. Так при чём здесь «стабильность ядра»? Она более чем достаточная. Если не рукоблудить безумно.

Бред дальше поскипан. Это позиция человека который пишет только в userland
«до ядра еще надо дотучаться» «а вот в userland оно все стабильно» - а вот что делать с теми мегабайтами кода которые должны работать в режиме ядра ?

Как hint - могу предложить взять простейшее.. какой нить драйвер из 2.6.5 и попытаться портировать его в 2.6.30. Я посмотрю сколько у вас уйдет времени.
И насколько безболезненым будет для вас этот процес ;-)

> Интересно какой вменяемый руководитель будет считать что регулярное внесение такого объема изменений благотворно скажется на стабильности продукта? А стоимость работы программистов по портированию кода на новое ядрышко? А затраты на поддержание стабильной ветки? Нет уж.. total cost of ownership в случае Linux получается запредельным.

Вы знаете, драть последний тельник на голой груди (как вариант — «голыми руками волосы на голой заднице») можно много, нудно и долго. Давайте проще:

1.

Цена поддержки сложного приложения (~20M кода) который работает со практически всеми подсистемая ядра (VFS, MM, block device, FS, Network - включая RDMA transfer).

Про 20М кода оставим в стороне, считаем, что это так... Пустячёк.

По подсистемам ядра. Простите, а вы что там используете низкоуровневые вызовы? Свои сисколы что ли ваяете? Что, те же интерфейся к VFS это уже не модно стало использовать и очень хочется «порулить всем» напрямую? Если Вы пишете _такой_ код, то... Расстреляйте что ли своего «системного аналитика»... Для начала...

Этот подход просто _гарантирует_ запредельность стоимости разработки.

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

Посмотри на 1 пост выше своего.

К.О.

«кажется облажался» ? :)

>> Название проекта - достопочтеный Дон может сам найти - оставлю это на домашнее задание :-)

проект не назвали, но миграция-то куда происходит? куда-нибудь на solaris?

>В QNX? Нет. Там не одно, так другое, плюс заточка только под определённые вещи.

API довольно стабилен.

В Linux? Ну, сами говорите — нет, хотя, вопрос и спорен (да, в своё время, если наложить патчи Инго Молниера, то можно было получить аналог QNX, какая уж тут «стабильность»?).

В этой помойке стабильны только баги. Студенты, чо поделаешь.

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

В венде все довольно-таки стабильно. Факт. По крайней мере по сравнению с ляпихом.

Во... фряхе? Ой, и этого ненадо, ладно? В каждой избушке, знаете ли, свои погремушки. «Стабильный API» = «мёртвый и неразвивающийся API».

Угу-угу. Факты?

> amd64 на дектопе не понятно. Over 4GB памяти усреднённому разработчику вроде как не к чему.

Один инстанс g++ запросто может пожирать более 1 Гб памяти на плюсовом коде. Компиляция с make -j4 загоняет машину в своп, убивает кеш файловой системы. А у меня еще виртуалбокс с тестами крутится, кеды, почта, файерфокс с ЛОР-ом открыт.

Бзунишки хором мямлят свое «ни к чему» по одной-единственной причине: у них до сих пор нет стабильного драйвера с поддержкой Over 4Gb.

> Подписку на lkml оставлю вам на домашнее задание.

Ой, Учитель, а она уже есть... Примете? :)))))))))))

Бред дальше поскипан. Это позиция человека который пишет только в userland

Угу. Нет. Вы не правы. Это позиция человека, который отчётливо понимает что цена вопроса в случае, если лезем _без_башки_ в ядро, нам там башку и оторвут. И который явственно понимает что _так_ просто изменения в API ядра не вносятся. По сути дела, они вносятся так, чтобы по возможности не затрагивать уже существующие интерфейсы. Всё остальное (про 20 метров кода в ядре) я оставляю на Вашей совести. Наверное, оно и правда.

Как hint - могу предложить взять простейшее.. какой нить драйвер из 2.6.5 и попытаться портировать его в 2.6.30. Я посмотрю сколько у вас уйдет времени.

И насколько безболезненым будет для вас этот процес ;-)

И... Чего дальше? Мои модули под некоторые железочки нашей разработки дай Бог, благополучно были портированы с ветки 2.18, под кою и разрабатывались, вначале в 2.4, теперь вот в 2.6.*. Только я ни когда не был олухом Царя Небесного, ни чего не читающим окромя своих исходников. Так что, всё было абсолютно ровно и безболезненно.

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

P.S. Лично я из спора выхожу ввиду его полнейшей бесперспективности.

>Один инстанс g++ запросто может пожирать более 1 Гб памяти на плюсовом коде. Компиляция с make -j4 загоняет машину в своп, убивает кеш файловой системы. А у меня еще виртуалбокс с тестами крутится, кеды, почта, файерфокс с ЛОР-ом открыт. Бзунишки хором мямлят свое «ни к чему» по одной-единственной причине: у них до сих пор нет стабильного драйвера с поддержкой Over 4Gb.

Оу, клоунада начинается, клоуны приползли. Без вас тут было скучно, гавкать было некому :)

Моншер, а вы самокритичны. Правда, вы уже давно в сией теме, не?

>Моншер, а вы самокритичны. Правда, вы уже давно в сией теме, не?

Ладно уж гавкать, давайте по существу.

Нееее... Такое не откомментить... :))))))))))))))))))

API довольно стабилен.

При использовании на i386? Изумительно. А больше и не неужно... :))) Вы, батенька, давно ли с QNX ручками работали?

В этой помойке стабильны только баги. Студенты, чо поделаешь.

«Чо»... Мдяяя... В натуре, брателло, ЧО поделаешь... :))))))))) Хотя, эт ништяк што студенты, а не из ГПТУ (из «Господи, Помоги Тупому Устроиться») и не пацаны с раёна.

В венде все довольно-таки стабильно. Факт. По крайней мере по сравнению с ляпихом.

Слышь, ЧО, брателла, тыб масла се в башку в натуре долил бы штоль? А то наверняк там оно у тя выкипело. На ручнике долго не езди... :)))))) Ты хоть вкурил чё в вянде висте и семёрке произошло? Не? Ну, лады, рассказываю. Прикинь, братан, там API поменяли. Старьё из программья работает тока в режиме обратной совместимости. Это те не шубу в трусы заправлять...

Угу-угу. Факты?

А ты чё, в натуре штоль читать не умеешь? Или с мозгами напряг недетский?