Ух, сколько противников сборки ядра повылазило. Ниасилили? Зачем публично оправдываться и убеждать всех в том, что дефолт - это круче чем самопальное? Сколько ваше дефолтное весит?
% du -sh /boot/vmlinuz-2.6.19-ck2-r1
1.3M /boot/vmlinuz-2.6.19-ck2-r1

>Или вы еще не в курсе как проявляется увлечение оптимизацией? Тогда поставьте Gentoo и поиграйтесь с CFLAGS.

За 5 лет "не в курсе", расскажите...

Re:

> Тогда подскажи, пожалуйста, дистрибутив, в котором дистростроители не пихают в ядра и initd всякой дребедени.

Что, кого-то сильно беспокоит, что "всякая дребедень" загружается только при необходимости, а не торчит в ОЗУ все время?

> да, аж целых 15 минут - лучше, наверное, пойти покурить

Моё за 4 минуты собирается, господа лузеры. И не занимается собираением всякого идиотизма, который мне заведомо не нужен.

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

Именно поэтому я ни разу не видел panic на своём самосборном generic-ядре, которое использую каждый день. И видел их на дистрибутивном, супервылизанном, из всяких шапок и кепок.

> Анонизма ровно стока, чтоб подсунуть новому ядру конфиг, собраться и ребутнуться.

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

> Ух, сколько противников сборки ядра повылазило. Ниасилили? Зачем публично оправдываться и убеждать всех в том, что дефолт - это круче чем самопальное? Сколько ваше дефолтное весит?

Дык елки, мы-то лохи! ниасилили конечно! Нам в ПТУ не объяснили.

>вы наивно считаете, что ядро во всю активно использует расширения команд SIMD SSE/SSE2/SSE2/MMX/MMX2 современных x86 процессоров?

я не считаю, я знаю: /arch/i386/lib/mmx.c

А если для работы нужно ядро со специфичными патчами? Я например собираю с realtime-preempt для работы со звуком в реальном времени с минимальными задержками. Этот патч находится в активной разработке, поэтому имеет смысл периодически его обновлять. Можно конечно скачать готовое с PlanetCCRMA, но мне быстрее скачать патч в 2 MB и пересобрать ядро, чем качать несколько десятвов мегабайт. Кроме того, для таких задач нужна тонкая настройка ядра.

В общем, задача сборки ядра актуальна и книга полезна.

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

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

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

На какие? 4 минуты на сборку ядра? Дядя, ви делаете смешно моим тапочкам. Кто-то тут про 15 минут и кофе распространялся.

И ещё раз: как показала практика, собранное мной лично generic-ядро работает и не глючит. А дистрибутивных вечно что-то не слава богу.

Это все можно сделать в рамках одной версии ядра (типа для всех 2.6.18.*).
Только, собственно, зачем? Опять вы в крайности впадаете? (типа, пересобирать ядро каждый день)

Включил просмотр анонимных комментариев. У оказывается сколько у нас анонимных любителей сборки ядер 8))))

> я не считаю, я знаю: /arch/i386/lib/mmx.c

Может, я не прав? На самом деле, это просто реализация memcpy через регистры SIMD.

>Религия мешает установить kernel-image-2.6.8-2-k7?

Нет, кухонный комбайн для намазывания масла на хлеб мне не нужен :D

> ты быстро увидишь разницу между -march=athlon-xp и -march=i386, я тебя

> уверяю

Бред сивой кобылы. 100%-ная чушь. Разницы *никакой*. *Вообще*.

Re:

Эта дребедень долго думает что грузить, а что нет. Кого как, а меня напрягает, что комп грузится не за 30 секунд (WinXP, Gentoo), а за 70 (Fedora).

Подробнее объяснили чуть выше.

Да, некоторые вещи сделаны "ручками" на асме под определённые процессоры, generic-кодом занимается компилятор

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

Очень даже считаю, что не совсем все понимают, пример не коректная работа mgetty под дефолтовым ядром в шапке 7.2

>> > ты быстро увидишь разницу между -march=athlon-xp и -march=i386, я тебя

>> Бред сивой кобылы. 100%-ная чушь. Разницы *никакой*. *Вообще*.

Ну я конечно не скажу что оно в 5 раз быстрее будет работать, но *никакой* - это и есть бред сивой кобылы.

>Бред сивой кобылы. 100%-ная чушь. Разницы *никакой*. *Вообще*.

Бред анонимуса. 100%й-флуд. Мышления нет *никакого*. *Вообще*.

> Ну я конечно не скажу что оно в 5 раз быстрее будет работать, но

> *никакой* - это и есть бред сивой кобылы.

Нет прироста в производительности никакого абсолютно между самым минимальным ядром, какое только возможно, и самым полным ядром. Это подтверждают многократные тесты как mysql/postgresql bench, так и тесты типа ab и bonie++. Никакого прироста производительности пересборкой ядра добиться *невозможно*. Кстати, это написано и в FreeBSD/OpenBSD hand book'ах.

Пример:

http://openbsd.org/faq/faq5.html#Why

A: Why do I need a custom kernel?

Q: Actually, you probably don't.

Some reasons why you should not build a custom kernel:

* You do not need to, normally.

* You will !!! not !!! get a faster system.

* You are likely to make a less reliable machine.

* You will not get any support from developers.

* You will be expected to reproduce any problem with a GENERIC kernel before developers take any problem report seriously.

* Users and developers will laugh at you when you break your system.

* Custom compiler options usually do a better job of exposing compiler problems than improving system performance.

> * Custom compiler options usually do a better job of exposing compiler

problems than improving system performance.

Эта строчка спецально для юзера R00T :-)

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

> А сколько по времени depmod при ребуте делается?

На фоне загрузки - нисколько. Читай man depmod -без принудительных ключиков он только смотрит изменения на основании таймстампов файлов.

> А сколько это все оперативки жрет?

Нисколько. Это все МОДУЛИ. Они загружены только когда используются.

> Но не проще ли тогда вообще пересобрать ядро под конфигурацию машины?

И при покупке очередной железки пересобирать ядро? Нафиг-нафиг. Однажды у меня за три дня в компе перебывали три сетевые - на чипах Intel, 3COM и VIA. А не заколебался бы я ядро компилить каждый раз?

> Вы хотите сказать, что этот "дядя" поумнее Линуса&Co. будет, да?

"Линус&Co", понимаешь ли, не могут протестировать все для всех комбинаций. А дядям другие дяди дают багрепорты, по которым делаются патчи, которые потом "Линус&Co" включают в основную ветку.

> * You do not need to, normally.
> * You will !!! not !!! get a faster system.
> * You are likely to make a less reliable machine.
> * You will not get any support from developers.
> * You will be expected to reproduce any problem with a GENERIC kernel before developers take any problem report seriously.
> * Users and developers will laugh at you when you break your system.

Все понятно. Обычный маркетоидный бред в стиле: "Не меняйте самостоятельно пылесборник в пылесосе! Вы можете... {далее следует список Самых Ужасных Событий, Которые Могут Произойти С Человеком, Меняющим Пылесборник В Пылесосе}. Лучше обратитесь к Нашему Специалисту, который профессионально сменит пылесборник в Вашем пылесосе!"

> * Custom compiler options usually do a better job of exposing compiler problems than improving system performance.

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

Re:

>Видать тока гента....

LFS

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

Ты упал? Вообще-то, они давно дергают кудзу, а тот через lspci/lsusb смотрит что это за девайс и какой драйвер ему надо...

> Например, если у вас в дефолте грузятся только модули VIA-SATA, а вы сменили платформу на VIA

Только в отличие от тебя, я просто загружусь с livecd/rescuecd и просто перезапущу mkinitrd с нужными ключами. А ту отправишься компилировать ядро.

> Приятно вам сознавать, что ваш какой-нибудь PentiumD работает на самом деле просто как разогнанный до 3-х ГГц Pentium2?

Ты блин ... или ,,,? Посмотри код ядра, и удивись тому, что 99% переменных - целочисленные, и для них эти "продвинутые" наборы инструкций - пустой звук. -march=i686 от -marc=athlon для таких данных отличается на проценты - и то только при 100% нагрузке. И чтобы %sys занимал значимый процент процессорного времени - это еще надо ну очень постараться.

На самом деле, там реализовано 3 функции: EXPORT_SYMBOL(_mmx_memcpy); EXPORT_SYMBOL(mmx_clear_page); EXPORT_SYMBOL(mmx_copy_page); И они используются всеми подсистемами ядра вместо неоптимизированных аналогов, если задана опция CONFIG_X86_USE_3DNOW

> Эта строчка спецально для юзера R00T :-)

А ВЕСЬ текст написан специально для дебилов, которые лезут пересобирвать ядро, не понимая, ЗАЧЕМ это может быть нужно. Если человек имеет достаточно опыта+знаний и не собирается клянчить помощи у kernel team в случае неудачи, этот текст его не касается - он сам прекрасно знает, что и зачем делает.

>> я не считаю, я знаю: /arch/i386/lib/mmx.c >Может, я не прав? На самом деле, это просто реализация memcpy через регистры SIMD.

На самом деле, там реализовано 3 функции: EXPORT_SYMBOL(_mmx_memcpy); EXPORT_SYMBOL(mmx_clear_page); EXPORT_SYMBOL(mmx_copy_page); И они используются всеми подсистемами ядра вместо неоптимизированных аналогов, если задана опция CONFIG_X86_USE_3DNOW

> Моё за 4 минуты собирается

После make mrporper? Сказочник блин нашелся...

А оно у тебя на HP Proliant с LSI-шным рейдом и адаптековской сказей забутится? А сколько времени ты будешь конфигурить перед сборкой ядро, которое таки забутится?

А на моем буке, у которого PCMCIA-ный DVD-привод оно его подхватит?

> Это если вы ручками покапаетесь как следует, потюните атолоадер и прочее...

Не тюнил. Система Debian. Грузится только то, что необходимо, оно и
не удивительно, учитывая подобные строки "alias:
pci:v000010B7d00005900sv*sd*bc*sc*i*" у модулей ядра.


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

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


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

Какой тюнинг то? :)

> А часто вам приходится менять встроенные сетевухи и звуковухи?

Встроенной гадостью не пользуюсь, одних звуковух с десяток в одной
машине менял пока не остановился на приемлимой, сетевухи тоже менял и
ни разу не испытывал желания после этого пересобирать ядро и,
собственно, не пересобирал. Лучше объясните в чем глубокий смысл
тратить время на сборку custom ядра, когда штатное _рекомендуемое_
ядро, в отличие от ваниллы, где то микшер emu10k сломают, то ext3
навернут, то у saa7134 сломают IR, то MTRR на некоторых камнях
неправильно инициализируется, поддерживает установленное железо "из
коробки"? Когда не поддерживает - это уже другой вопрос. И в gentoo
такой же идиотизм - вместо того, чтобы софт изначально делать
модульным с поддержкой плагинов городят монолит с #ifdef-ами и --with/
--without, а также USE-флагами, чтобы пользователи маялись дурью,
собирая необходимые плагины, вместо того, чтобы иметь возможность
загрузить или не загружать уже готовые плагины.

> А что касается платформы, то (скорее всего) некие телодвижения
придется делать в ЛЮБОМ случае. Например, если у вас в дефолте
грузятся только модули VIA-SATA, а вы сменили платформу на VIA, то
ядро вам при загрузке нарисует что-то типа "root fs not found, kernel
panic".

Нет не придется, что подтверждается собственным опытом переезда с
платформы на платформу на модульном ядре. man initrd.

> Вас послушать, так вы в день по 100 раз меняете конфигурацию своего
компа? Матери, процы, винты, звук, сеть?

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

> Оно сохраняет регистры SIMD блоков при переключении контекстов. Что
дает возможность делать "-O3 -march=nocona -msse -mfpmath=sse3". "-
msse -mfpmath=sse3" позволит компилятору использовать SSE, а "-O3"
дает внутри "-finline-functions", что в итоге позволяет передавать
параметры функций через регистры SSE - а они большие и даты в них
лезет много.

:) Учите матчасть.

/*
* linux/arch/i386/kernel/i387.c
*
* Copyright (C) 1994 Linus Torvalds
*
* Pentium III FXSR, SSE support
* General FPU state handling cleanups
* Gareth Hughes <gareth@valinux.com>, May 2000
*/

> Нет, не проблема. Совсем по другой причине, которую вы, по
недалекости своего ума, с ходу отвергаете.

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

> Уже огласил. 30-50% производительности только для мускля 4.1. А по
расходу памяти будет сравнимо, разумеется.

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

int save_i387( struct _fpstate __user *buf )
...

if ( HAVE_HWFP ) {
if ( cpu_has_fxsr ) {
return save_i387_fxsave( buf );
} else {
return save_i387_fsave( buf );
}
}
...

> Они-то понимают. Это вы не понимаете. Задача сборщиков
дистрибутивных ядер в том (и ТОЛЬКО в том), чтобы свежеустановленный
дистр запустился на максимальном количестве компов.

Это вы не понимаете, что увеличение произ-ти в полпроцента не
оправдывает часы на пересборку ядер и разгребание проблем с тучей
переоптимизированных систем. Там, где векторные инструкции
действительно увеличивают производительность, там они и
задействуются, автоматически. Вы видимо, не представляете, что с
помощью cpuid возможно автодетектирование поддерживаемого процессором
набора команд и автоматическое использование этих команд. Будущее -
за модульными ядрами и софтом, автодетектирующим наличие расширений
команд, а не за тупым софтом, который нужно затачивать под каждую
конкретную ситуацию и котором нужно явно объяснять, какие расширения
команд имеет данный процессор путем пересборки с #define-ами.

ЗЫ
2 модератор: грохните плиз неотформатированный предыдущий пост.

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

Дааа? :-) А какой именно дистр делает depmod без ключиков, если не секрет? :-)

> Нисколько. Это все МОДУЛИ. Они загружены только когда используются.

О как! И прямо-таки оно не грузит сдуру MD-RAID, кучу SATA/IDE контроллеров и прочего?
Звук и сеть - фиг с ними, можно и через autoloader. А вот с дисковыми контроллерами чуть сложнее.

> И при покупке очередной железки пересобирать ядро?

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

> Однажды у меня за три дня в компе перебывали три сетевые - на чипах Intel, 3COM и VIA. А не заколебался бы я ядро компилить каждый раз?

Тоже бывало, когда требовалось что-то необычное - например, подключить винт с ext3 (при том, что у меня везде reiserfs). Ничего, меня пересборка не напрягла совершенно.

> другие дяди дают багрепорты

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

> Все понятно. Обычный маркетоидный бред в стиле:

Ну конечно. И линукс программеры и BSD программеры - все идиоты. Один r()()t - граф Монте-Кристо на белом коне :-)

> После make mrporper?

На новом ядре, которое я слил с kernel.org и распаковал. И подсунул свой конфиг. Это:

make bzImage && make modules

> Сказочник блин нашелся...

Дядь, у меня CoreDuo. И выкинуты ВСЕ ненужные опции. В отличие от вас, привыкших тянуть с собой ВЕСЬ ненужный хлам - видимо, в надежде, что он пригодится потомкам.

> А оно у тебя на HP Proliant с LSI-шным рейдом и адаптековской сказей забутится?

Нет. А ещё оно мне кофе не сварит и зимнюю резину на летнюю не поменяет. Это ноут, дядь.

> А на моем буке, у которого PCMCIA-ный DVD-привод оно его подхватит?

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

Хорошая книжка. Великолепно, что она свободна для скачивания. Наверное, сегодня её даже распечатаю. Кстати, там в ссылках на скачивании вместо pdf главы 11 повторяется 8я... В архиве всё нормально. А куды содержаие кладут - в начало книжки, или в конец?:) То там нумерация вне всей книги, римскими цифрами, и непонятно куды его совать..

> 2 модератор: грохните плиз неотформатированный предыдущий пост.

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

> make bzImage && make modules

> Дядь, у меня CoreDuo.

Ну так почему у тебя нету флага -j2 в вызове make? Забыл, или таки ты сказочник?

>Ну так почему у тебя нету флага -j2 в вызове make?

для C2D -j2 маловато будет ;)

> низкая скорость запуска системы + не всегда корректное определение оборудования

Вы перезагружаете систему каждые десять минут? С ванильным самосборным ядром проблемы отсутсвуют(а то прекрасно помню и некорректное определение avertv 305 и проблемы с MTRR и свежие пробелмы с ext3 и отвалившийся IR у saa7134 и отвалившийся микшер у emu10k)?

> раз в 1-5 лет?

Чаще

> При появлении очередной уязвимости кому-то, конечно, проще мегабайты перекачать, а кому-то - несколько кбайт патч и 10 минут на make bzImage

А у кого-то вообще нет доступа в Интернет - им проще заказать диск с обновлениями, а еще проще вообще не обновляться. При наличии ноормального канала установка готового пакета происходит быстрее выкачки патчей, их применения, корректровки старого конфига , сборки и установки, более того такой процесс АВТОМАТИЗИРУЕТСЯ, а значит МАСШТАБИРУЕТСЯ на произвольное число машин, а это экономия времени на обслуживании и соот-но денег.

> да, раньше это было именно развлечением, теперь мне за подобные вещи платят

> Если для кого-то это "убитое" время (6-9 минутная компиляция не в счёт) - для меня это _штатные_ люди, просто защищающие чью-то позицию.

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

Полистал. Пожалуй глава 9 в качестве склерозника по параметрам загрузки ядра потянет (видимо редко перегружаюсь) ;)

> И чтобы %sys занимал значимый процент процессорного времени - это еще надо ну очень постараться.

Да сплошь и рядом даже современных машинах. До 40% - это даже не вопрос.

>>Ну так почему у тебя нету флага -j2 в вызове make?

>для C2D -j2 маловато будет ;)

Но у него же вообще никакого нет.

А почему для C2d -j2 мало? У него 2 коры. Имеется в виду HyperThreading или что?

>А почему для C2d -j2 мало? У него 2 коры. Имеется в виду HyperThreading или что?

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

>> * Custom compiler options usually do a better job of exposing compiler problems than improving system performance.

>Ну так надо сначала почитать маны, подумать что делаешь, потренироваться на кошках, а только потом уже что-то серьезное делать...

А нафига? Если и так всё работает. Не лучше ли заняться чем-нибудь полезным? Пиффка там попить, с деффками пообщаться :-)

>А у кого-то вообще нет доступа в Интернет - им проще заказать диск с обновлениями, а еще проще вообще не обновляться.
>При наличии ноормального канала
>sysenter

На ЛОРе модно быть тупым ? интернет это либо толстый канал либо его вообще нет, остальные варианты будешь отрицать ?

> Ух, сколько противников сборки ядра повылазило. Ниасилили? Зачем
публично оправдываться и убеждать всех в том, что дефолт - это круче
чем самопальное? Сколько ваше дефолтное весит?
% du -sh /boot/vmlinuz-2.6.19-ck2-r1
1.3M /boot/vmlinuz-2.6.19-ck2-r1

$ ls -lh /boot/vmlinuz-2.6.8-2-686
-rw-r--r-- 1 root root 1,2M 2005-08-16 21:14 /boot/vmlinuz-2.6.8-2-686

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

>>Или вы еще не в курсе как проявляется увлечение оптимизацией? Тогда
поставьте Gentoo и поиграйтесь с CFLAGS.

>За 5 лет "не в курсе", расскажите...

Вам с линками на багзиллу или хватит

grep -r replace-flags /usr/portage/
grep -r O3 /usr/portage/

?

Есть еще один такой замечательный сайт funroll-loops.org, который
сейчас, к сожалению, лежит. Вам туда :)

> Нет не придется, что подтверждается собственным опытом переезда с
> платформы на платформу на модульном ядре. man initrd.

О! Еще и initrd мы включим! Сколько там по дефолту создается? 8 RAM-дисков по 32 мега? Подумаешь, фигли нам, пацанам, 256М туда, 256М сюда...

> Поддержка SSE в Linux с 2000 года, при чем наличие SSE и
> задействование fxsave происходит автоматически, безо всякого
> вмешательства гуру, который проинструктирует ядро, что процессор
> поддерживает SSE.

Ну конечно, а gcc кто об этом проинформирует? Вася Пупкин?
Ядро _НЕ_ выполняет математических операций через SIMD, да будет это вам известно:
r00t@root:/usr/src/linux-2.6.19.1/arch/i386$ cat ./Makefile | grep "msoft-float"
CFLAGS += -pipe -msoft-float

Соответственно, есть только 1 возможность использовать SIMD: как дополнительные регистры общего назначения. :-) Ну, если хотите, как сверхбыструю кеш-память. Упоминавшийся выше mmx.c использует регистры SIMD для копирования блоков памяти. "-O3 -march=nocona -msse -mfpmath=sse3" позволяет хранить аргументы вызываемых функций в регистрах SIMD. В чем проблема, я не понимаю? Что, собственно, вы мне пытались доказать?

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

Кажется, чуть выше я писал, что не "полпроцента", а 30-50 процентов.
Не "часы", а считанные минуты. "Часы" могут понадобиться на чтение документации и подбор оптимальных опций. Ну и что? Изучение чего-то нового всегда требует времени, независимо от того, что изучается.
Блин, какие "проблемы"? Откуда?

> Будущее - за модульными ядрами и софтом, автодетектирующим наличие расширений команд

Что-то на рекламу венды похоже. Которая тоже вумная-вумная. Тока отрубями не питается.
Это все ради ленивых балбесов, которым лень научиться ядро собирать?

> которым лень научиться ядро собирать?

А зачем это делать?

>> Дядь, у меня CoreDuo.

> Ну так почему у тебя нету флага -j2 в вызове make? Забыл, или таки ты сказочник?

Может, намеренно не сделал, не знаю. Я вот сейчас попробовал "time (make bzImage&&make modules)" на Athlon64-X2-3800+, ядро 2.6.18.6, и получил real=6m59s. Так что почему бы и нет. Ядро конфигурировал именно под эту машину, ничего лишнего.

>off: Ананимус! Перекомпилируй его с поддержкой проводной сети и задушись проводом!

А с поддержкой беспроводной сети он задушиццо и без провода :)
PS: Мой ник не при чём :)