Линус Торвальдс объявил (http://permalink.gmane.org/gmane.linux.kernel/887588) в списке рассылки Linux ядра о выходе релиза 2.6.31. В новое ядро принято около 12 тысяч исправлений от 1356 разработчиков, размер патча - 57Мб (добавлено 923 тыс. строк кода, удалено - 513 тыс.). 70% всех изменений связано с инфраструктурой драйверов и еще 6% связано c прошивками (firmware) и звуковой подсистемой, что значительно больше неформального баланса "50% изменений в драйверах и 50% во всем остальном". Примерно 11% изменений имеют отношение к поддержке различных аппаратных архитектур (ARM, mips, powerpc, sh, x86) и примерно столько же приходится на код, обеспечивающий работу файловых систем.
Основные новшества (http://kernelnewbies.org/Linux_2_6_31):- Поддержка USB 3.0 и хост-контроллеров, соответствующих спецификации xHCI 0.95 (eXtensible Host Controller Interface). Стандарт USB 3.0 определяет в качестве максимальной скорости передачи данных через USB интерфейс - 4.8 гигабит в сек., что...
URL: http://permalink.gmane.org/gmane.linux.kernel/887588
Новость: http://www.opennet.me/opennews/art.shtml?num=23357
> увеличение интерактивности при работе с десктопом примерно в два раза;Новость не может не радовать.
P.S. Жду, четную(стабильную) версию ядра.
>P.S. Жду, четную(стабильную) версию ядра.Это давно неправда. Уже все версии одинаково стабильны вроде (или я заблуждаюсь и это все еще правда?)
>Это давно неправда.Правда, но для второй цифры, а здесь третья меняется.
>>P.S. Жду, четную(стабильную) версию ядра.
>Это давно неправда. Уже все версии одинаково стабильны вроде (или я заблуждаюсь
>и это все еще правда?)Вообще-то чётными должны быть вторые цифры, а не третьи.
2.0.*; 2.2.*; 2.4.*; 2.6.* - это стабильные ветки.
2.1.*; 2.3.*; 2.5.* - это нестабильные ветки.Но начиная с ветки 2.6 ядро перешло на новый режим: все версии объявляются нестабильными и девелоперскими. Сейчас "чётный/нечётный" номер ветки уже потерял актуальность. ИМХО так.
Да.
отлично, линуксоиды и сами не знают что у них стабильное, а что не стабильное, отлично.
>отлично, линуксоиды и сами не знают что у них стабильное, а что не стабильное, отлично.99,9% виндузятников тоже не знают в каком файле храниться их ядро.
ну и что?если ядро не имеет постфикса rc - значит стабильное.
и то - это если только ядро брать (самому!) с kernel.org!
а последнее стабильное в дистре - это то, что можно скачать из реп дистра.
>Новость не может не радовать.Не совсем. Процесс выпуска новых ядер отлажен до мелочей, спорить не буду, а вот с "внутренней кухней" не все так гладко. Одни "улучшение средств по выявлению ошибок в ядре" - удар по самолюбию Линуса, он же спокойно выполнять свои координаторские обязанности не может, в горячем финском хлопце кровь играет. А главному технарю Мортону приходится работать за двоих.
>Включение в состав KMS
RadeonHD драйвер закроют, разработчиков уволят :D
А вообще, ИМХО, им стоило бы задуматься над выпуском "корректирующих релизов", "ревизий" и прочих технологий контроля качества, а не новые драйверы/фичи добавлять. Что-то добавить в ядро не такая уж проблема, а вот внести изменение или что-то удалить потребует проведения ревизии всех подсистем/драйверов. То, что этим до сих пор не начали заниматься очень печально.
>>Включение в состав KMS
>RadeonHD драйвер закроют, разработчиков уволят :DKMS для драйвера всего лишь api, точно такой как UMA/GEM
>KMS для драйвера всего лишь api, точно такой как UMA/GEMТолько драйвера по сути не остается. Все, что работает с железом, ядром и может работать с другими драйверами (например с контроллером памяти, если видеокарта встроена в чипсет) переносят в ядро. OpenGL тоже в ядре: DRI, DRM. А так да, всего лишь API.
Нормальной поддержки 3D для Linux пока никто не реализовывал (это касается вообще всех) - не хотят связываться с зоопарком технологий, а во-вторых оторванный от железа OpenGL. Все железо написано исключительно под DirectX, под слишком высокоуровневый OpenGL невозможно оптимизировать железо т.к. железка тупо будет значительно дороже стоить.
Здесь даже крайних нет, как ни крути, со всех сторон у Linux с 3D засада.
Как раз дело с графикой сдвинулось с практически с мертвой точки.Да к сожалению (или всетаки к счастью?) невозможно все резко перевести на новый интерфейс, поэтому приходится поддерживать зоопарк интерфейсов.
В общем я думаю ближайший год покажет жизнеспособность kms/dri2/gem/gallium.
этот галиум придумали, чтобы пойти навстречу производителям карт....
им на линух просто наср.ь... на винде бы удержаться.а kms/dri2/gem/ - не имеют отношения к 3d вообще и opengl в частности.
Большей глупости не слышал. Что курил?
если бы хоть немного разбирался - эту чушь не написал бы.
хотя... можешь попробовать поспорить и привести пруфлинки.
поясню (а то может и правда за идиота примут :-D)1. dri - предоставляет прямой (direct) и безопасный доступ к видео-карте (graphics hardware) и её функциям. в том числе и к её 3d-возможностям. но без user-space библиотеки тип mesa (собственно, пока только она) смысла не имеет
2. kms - механизм смены видеорежимов средствами ядра
3. DRM (Direct Rendering Manager) это дополнение к Xorg, которое добавляет поддержку 3D ускорения для видеокарт, путем добавления модуля ядра, специально предназначенного для поддержки аппаратного ускорения.а вот далее идут 3д-дрова, которые и управляются этой инфраструктурой и в общем то только
в общем 3d-приложения всё равно нуждаются в посреднике (типа mesa - реализация opengl) и напрямую не работают. теоретически можно было бы сделать реализацию и directx.
производительность зависит от этих дров и реализации opengl (для всех, кроме nvidia - это mesa)
> производительность зависит от этих дров и реализации opengl (для всех, кроме nvidia - это mesa)Это не есть правда. У ATi (драйвер fglrx) своя реализация. Возможно, у VIA тоже своя.
спорить не буду. возможно.
говорил то о другом - что учавствует в формировании картинки, а что является инфраструктурой для работы первого.
>под слишком высокоуровневый OpenGL невозможно оптимизировать железоВсегда считал, что Direct3D гораздо более высокоуровневый интерфейс, чем OpenGL.
>Всегда считал, что Direct3D гораздо более высокоуровневый интерфейс, чем OpenGL.Это не верно, т.к. в Direct3D, к примеру, нужно самому рассчитывать видовые матрицы и ещё много чего, что не вшито в драйвер как в OpenGL. Поэтому возможностей для оптимизаций/упрощений для конкретных случаев гораздо больше.
Топикстартер троллит. Чтобы у незамутнённого читателя возникла сама собой иллюзия, что в этолм непонятном Linux всё глючит, и мелочи, и самое главное. От смены курсора до драйверов устройств. Что софт ненадёжный. И что геммороя с ним хлебнуть придётся немало...
Пока что наблюдаю это только с виндовсом.
хорошь гнать!
от нвидии opengl (что в винде, что в линухе) идёт тыщу лет с одной и той же версией.
DRI, DRM - не имеют отношения к opengl.
и меса в ведро не грузиться.зы:
движок от квейка 3 работает в линухе визуально не хуже, но быстрее.
ззы:
интересно, такие комменты специально заказывают... с претензией на "правду"?
>>от нвидии opengl (что в винде, что в линухе) идёт тыщу лет с одной и той же версией.Ну так его никто не менял. Расширений от nvidia - вагон. А сам стандарт не nvidia устанавливает.
так то оно так, но реализация и её качество - многое значат.
не говоря о версии:
$ glxinfo
.......
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8400M GS/PCI/SSE2
OpenGL version string: 3.2.0 NVIDIA 190.25
OpenGL version string: 3.2.0 NVIDIA 190.32:-P
да не ставил я 32-е
лень... поставлю как-нить.
25 - не плохая сборка.
>движок от квейка 3 работает в линухе визуально не хуже, но быстрее.проводил тесты я недавно - работает он точно также, как и в win, разница в пределах погрешности при одинаковых настройках качества картинки
>>движок от квейка 3 работает в линухе визуально не хуже, но быстрее.
>
>проводил тесты я недавно - работает он точно также, как и в
>win, разница в пределах погрешности при одинаковых настройках качества картинкис 2004 года играю в квейк3 (джуст фор фун, но с профи) и могу тебя уверить, что под линь квака идёт гораздо быстрее чем под виндой, с теми же настройками и компом.
если бы ты не был ламериллой то уже давно прочитал консольные команды кваки и нашёл там com_maxfps который необходимо поставить в положение 99999. это необходимо для того чтобы квака не блокировала фпс на значении 100 (кажется).
неламериллы также знают про команду cg_drawfps который необходимо поставить в значение 1 , чтбы видеть кол-во фпс.
>Здесь даже крайних нет, как ни крути, со всех сторон у Linux с 3D засада.Хорошая такая засада. Пока вы тут пиндите, авторы например vendetta online денежки с этой засады стригут. И собственно - их движок отрисовывает приличную графику на 1280х1024 с хорошим FPS и практически максималными настройками на моем железе. Хорошая, черт возьми засада! И уж наверняка какая-нить анизотропная фильтрация при таком разрешении и FPS делается ну совсем без поддержки железом :).И все сцены считаются программно, ага.
>Только драйвера по сути не остается. Все, что работает с железом, ядром и может работать с другими драйверами (например с контроллером памяти, если видеокарта встроена в чипсет) переносят в ядро.Стандартизация и унификация это хорошо. А работы по прикручиванию ядрённых интерфейсов (drm<libdrm, менеджер памяти uma, kms), допиливанию месы для соответствия с последним ogl, dri/dri2-драйверов для хорга (а лучше сразу же ogl и dri2 через прослойку gallium) и так хватит.
>OpenGL тоже в ядре: DRI, DRM. А так да, всего лишь API.Бред, как и вообщем остальная часть поста
вот!
абсолютно согласен.
> RadeonHD драйвер закроют, разработчиков уволят :DУже уволили вроде кого-то? Да и фиг с ним - амд ясно дало понять что открытый драйвер для их карт будет рулить не этот. Ну и какие у RadeonHD после этого перспективы? oO
> То, что этим до сих пор не начали заниматься очень печально.
Как все любят учить других жить. А собственно, какого? Ядро пингвина при такой то сложности проекта ухитряется развиваться беспрецдентными темпами да еще и не становится при этом полным глюкодромом (я видел кучу проектов засравшихся в хлам при куда меньших темпах изменений). До того как лезть давать советы неплохо для начала хотя-бы обрисовать - а почему ваши советы вообще надо слушать.
Что до качества - скажу про файловые системы, а конкретно ext4. Не знаю кто там промыл мозги Теодору или его просто достали ругающиеся юзеры, но на баги он нынче реагирует довольно шустро и конструктивно. Итого - впечатления от автора ФС и от самой ФС в итоге пока что вполне позитивные. ФС - резвая. Фатальных багов - не вылазит вроде. А автор ФС еще и добивает ту мелочь которая появляется. Как по мне так с точки зрения QA - весьма прилично вроде все.
P.S. а вот у MS насколько я знаю используется в основном автоматическое тестирование (нормальная технология контроля качества, пойдет?). Что тем не менее, не мешает их драйверу NTFS %$аться в синий скрин в некоторых ситуациях когда с диска прочлось что-то не то. Линуксоиды баги похожего класса (oops при налете на совсем левые данные, etc) давят на раз. А микрософт на подобное не первый год кладет большой болт. У кого качественнее софт?
Буквально сегодня столкнулся с тем, что пропал весь /etc на разделе с ext4. Пришлось бэкап юзать. Всего-то хватило несколько раз через резет перезагрузиться. ФС шустрая, глюки, возможно, исправляют и быстро, но их все еще хватает.
> Буквально сегодняАналогично! Листал LWN:
>пропал весь /etc на разделе
>Всего-то хватило несколько раз через резет перезагрузиться.I recommend a sledgehammer.
If you want to lose your data, you might as well have some fun.
-- Rik van Rielhttp://lwn.net/Articles/348816/?format=printable -> http://lwn.net/Articles/348817/?format=printable
Ж)
>P.S. а вот у MS насколько я знаю используется в основном автоматическое
>тестирование (нормальная технология контроля качества, пойдет?). Что тем не менее, не
>мешает их драйверу NTFS %$аться в синий скрин в некоторых ситуациях
>когда с диска прочлось что-то не то. Линуксоиды баги похожего класса
>(oops при налете на совсем левые данные, etc) давят на раз.
>А микрософт на подобное не первый год кладет большой болт. У
>кого качественнее софт?разберитесь наконец в архитектуре NT, в принципах ее функционирования и не порите больше чушь:D так и должно быть. никсы на такие ошибки забивают и работают дальше, NT останавливается, чтобы данные не испортить.
Ога, данные в открытых приложениях не испортятся, если остановиться :D
> P.S. Жду, четную(стабильную) версию ядра.Лучше отпустите ручник... :)
> добавлена поддержка проброса IPv4 поверх Firewire;А разве этого не было раньше?
>> добавлена поддержка проброса IPv4 поверх Firewire;
>
>А разве этого не было раньше?В старом было, в новом нет.
Нигде не могу найти контроллер USB 3.0. И SATA 3.0. Раньше всё, что я хотел, находилось на Яндекс-Маркете. Долго ждать?
Ядро пока ещё собирается.
Сначала озаботьтесь поиском устройств с поддержкой USB3, чтобы было чем контроллеру управлять.
Я предпочитаю наоборот. А вот жёсткий диск куплю сразу.
USB 3.0 ещё физически не существует. только формат приняли и всё
Вроде разработан уже.
http://www.hwp.ru/news/Materinskaya_plata_ASUS_s_USB_30_i_SA.../
>Вроде разработан уже.
>http://www.hwp.ru/news/Materinskaya_plata_ASUS_s_USB_30_i_SA.../Мне бы PCI-платку...
Мне бы живые устройства, а то проблема стоит что втыкать, а не куда.
Зачем тебе PCI плата? У нее пропускная способность всего 33 MHz * 32 Bit = 1 GBit/s. Это теоретическое пиковое значение!
Тут уже минимум PCI-E x4 нужно ставить...
У меня PCI Express 16x 2.0 пустует. Спасибо, что разъяснил разницу! А то я раньше вообще не знал пропускную способность, а хотел узнать. Осталось только узнать, чем 2.0 отличается от PCI Express.
Асус вроде выпустила мать с первым усб3 портом
А ещё новые фишки
* Sysctl параметр для отключения загрузки модулей
sysctl -w kernel.modules_disabled = 1 (1 - незя, 0 - мона)# sysctl -w kernel.modules_disabled=1
kernel.modules_disabled = 1# modprobe -v 8250_pnp
insmod /lib/modules/2.6.31/kernel/drivers/serial/serial_core.ko
WARNING: Error inserting serial_core (/lib/modules/2.6.31/kernel/drivers/serial/serial_core.ko): Operation not permitted
insmod /lib/modules/2.6.31/kernel/drivers/serial/8250.ko
WARNING: Error inserting 8250 (/lib/modules/2.6.31/kernel/drivers/serial/8250.ko): Operation not permitted
insmod /lib/modules/2.6.31/kernel/drivers/serial/8250_pnp.ko
FATAL: Error inserting 8250_pnp (/lib/modules/2.6.31/kernel/drivers/serial/8250_pnp.ko): Operation not permitted-------
* Удален параметр ядра ramdisk=, теперь надо юзать ramdisk_size=
----------* Опции монтирования SSD дисков в BTRFS :)
mount -o ssd
mount -o nossd
mount -o ssd_spread (для большей производительности на дешёвых SSD дисках)А так же автоматическое определение SSD дисков, и автомонтирование их с параметром ssd.
--------* Теперь CIFS можно монтировать с опцией addr= - аналог ip= , т.е.
# mount -t cifs //192.168.0.1/SHARA /NET -o ip=192.168.0.1
# mount -t cifs //192.168.0.1/SHARA /NET -o addr=192.168.0.1одно и тоже
---------* Опция монтирования VFAT - errors, - определяет действия при глюках с ФАТом
mount -t fat|vfat -o errors=[panic,remount-ro,continue] /dev/sdx /media/wenda
Как видно из названия, при ошибках: в падать в panic, перемонтироваться в R/O, или пофиг.
------* По умолчанию, ECN работает только если оба конца поддерживают ECN.
sysctl -w net.ipv4.tcp_ecn = 0/1/2
0 - выкл.
1 - вкл.
2 - только серверная часть, если другой конец не поддерживает ECN, то равно выкл.По умолчанке: 2
------
и intel видюхами есть какие то улучшения ?
>и intel видюхами есть какие то улучшения ?i915
* Change GEM throttling to be 20ms (improves high-settings openarena performance on my GM45 by 50%)
* Add Display Port support
* Add chipset/feature defines for for new chipsets
* Enable kernel modesetting on IGDNG
* Add HDMI support on IGDNG
* Add LVDS support for IGDNG
* Add FIFO watermark support
* Enable error detection & state collection
* agp-intel: Add support for new chipsets
2.8.1 на 30 ядре - работаю нормально. (если вообще можно об интельных картах так говорить)
опенарена, смокинганс - работают НАМНОГО лучше, чем в виндах (в xp, не в висте)
в висте ещё хуже, если что.
>в висте ещё хуже, если что.В висте интельские дрова вообще периодически ставят систему в позу, так что порой только ресет помогает...
Linux netbook 2.6.31-10-generic #30~ppa1~nc10~jaunty-Ubuntu SMP Tue Sep 8 07:01:14 UTC 2009 i686 GNU/Linux
Полет нормальный
А толку то, TuxOnIce'а для 2.6.31 ещё нет :-(
> Удалось добиться уменьшения на 50% числа запросов, попадающих на вытесненные в раздел подкачки страницы памяти, и на 1/3 уменьшить число обращений к свопу (pswpin), что продемонстрировало в тестах увеличение интерактивности при работе с десктопом примерно в два раза;Имхо, какбе не принципиально 2/3 или 3/3 тормозов будет при своплении. Об интерактивности тут уже речи не может быть. :)
>> Удалось добиться уменьшения на 50% числа запросов, попадающих на вытесненные в раздел подкачки страницы памяти, и на 1/3 уменьшить число обращений к свопу (pswpin), что продемонстрировало в тестах увеличение интерактивности при работе с десктопом примерно в два раза;
>
>Имхо, какбе не принципиально 2/3 или 3/3 тормозов будет при своплении. Об
>интерактивности тут уже речи не может быть. :)Кагбе исходники ядра открыты - шлите свои предложения в виде патчей...
>Имхо, какбе не принципиально 2/3 или 3/3 тормозов будет при своплении. Об
>интерактивности тут уже речи не может быть. :)Ну не факт. То, что хотя бы дошло до разрабов, что надо код оптимизировать, а не ненужную функциональность тупо наращивать - уже хорошо.
Ну, купите тогда себе оперативки чтоли. Она нынче дешевая...
Как бы и я про то же. При нынешней стоимости памяти, очередной огород городить, имхо, не очень разумно.
>Как бы и я про то же. При нынешней стоимости памяти, очередной
>огород городить, имхо, не очень разумно.Нет, оптимизировать софт - это хорошо и правильно.Но если этому процессу еще и железо поможет - как-то лучше будет. Потому что скорость работы RAM и HDD сколько ни оптимизируй все-равно отличается на порядки.
Я затёк жиром, а потому куплю себе автомобиль, чтобы двигать в пространстве и времени своё тело
>Я затёк жиром, а потому куплю себе автомобиль, чтобы двигать в пространстве
>и времени своё телоЛень - двигатель прогресса :).Были бы люди не ленивые - до сих пор жили бы в пещерах и перемещали свое тело на своих двоих (и спасибо еще если не четырех).
И ничего из понаписанного тобой не отменяет того, что надо держать себя с форме
>продемонстрировало в тестах увеличение интерактивности при работе
>с десктопом примерно в два раза;
>Имхо, какбе не принципиально 2/3 или 3/3 тормозов будет при своплении.
>Об интерактивности тут уже речи не может быть. :)
Интересная концепция.
Патчег для последней SVN версии под 2.6.31Index: ramzswap.c
===================================================================
--- ramzswap.c (revision 437)
+++ ramzswap.c (working copy)
@@ -896,7 +896,7 @@
#ifdef SWAP_DISCARD_SUPPORTED
blk_queue_set_discard(rzs.disk->queue, ramzswap_prepare_discard);
#endif
- blk_queue_hardsect_size(rzs.disk->queue, PAGE_SIZE);
+ blk_queue_logical_block_size(rzs.disk->queue, PAGE_SIZE);
add_disk(rzs.disk);rzs.mem_pool = xv_create_pool();
P.S. через Меrcurial уже другой код :)
>[оверквотинг удален]
>+++ ramzswap.c (working copy)
>@@ -896,7 +896,7 @@
> #ifdef SWAP_DISCARD_SUPPORTED
> blk_queue_set_discard(rzs.disk->queue, ramzswap_prepare_discard);
> #endif
>- blk_queue_hardsect_size(rzs.disk->queue, PAGE_SIZE);
>+ blk_queue_logical_block_size(rzs.disk->queue, PAGE_SIZE);
> add_disk(rzs.disk);
>
> rzs.mem_pool = xv_create_pool();Я тоже поставил - правда на на 31-е ядро... Хоть и 2гига оперативы - все равно понравилось:)
в /etc/rc.local прописал:
swapoff /dev/sda5
cd /opt/compcache-0.6/
/opt/compcache-0.6/load_modules.sh 1
/opt/compcache-0.6/sub-projects/rzscontrol/rzscontrol /dev/ramzswap0 --reset
/opt/compcache-0.6/sub-projects/rzscontrol/rzscontrol /dev/ramzswap0 --memlimit_kb=524288
/opt/compcache-0.6/sub-projects/rzscontrol/rzscontrol /dev/ramzswap0 --init
swapon /dev/ramzswap0
swapon /dev/sda5cat /proc/swaps
Filename Type Size Used Priority
/dev/ramzswap0 partition 509224 7964 -1
/dev/sda5 partition 6032368 0 -2Система интересно себя ведет, когда дело до свопа доходит... Но то что резвее откликается - то это факт!
Не вижу в списке BFS.
Шутник...
поломали ACPI :-(
теперь только acpi_enforce_resources=lax или no
2D работает шустро, а 3D сломалось полностью :(
в 3D просто нет картинки...
аааааа! все просто шикарно, после установки mesa 7.5.1
glxgears
3467 frames in 5.0 seconds = 693.347 FPS
3449 frames in 5.0 seconds = 689.616 FPS:)
А до этого сколько было?
до этого было все совсем плохо с 3D, выдавало 50-60fps
Подожду 2.6.31.1, тогда уже буду ставить на сервера..
>_< на сервера??? последнее ядро на сервер боевой???
>последнее ядро на сервер боевой???Lf! А что не так??
>2.6.31Ребят, если кто ставил это ведро, отпишитесь об успехах? (и конфиг системы, плиз)
Я ставил его под VMWare с GoboLinux - не грузится :( Пишет, что не может найти root раздел (вирт. диск /dev/sda1). SCSI, ReiserFS, всё вкомпилил в ядро.
initrd, я так понимаю, тут не помощь.
update-initramfs -c `uname -r` || mkinitrd
>update-initramfs -c `uname -r` || mkinitrdК счастью или сожалению, у меня Gobo-linux, там упдате-инитрам нет, а мкинитрд сделан в виде перлового неработающего скрипта. Я делал инитрд руками, всё равно до него даже не доходила очередь - ядро падало ещё при своей инициализации.
Уверен, ещё пара недель и эти грабли таки откопают. :(
>>update-initramfs -c `uname -r` || mkinitrd
>
>К счастью или сожалению, у меня Gobo-linux, там упдате-инитрам нет, а мкинитрд
>сделан в виде перлового неработающего скрипта. Я делал инитрд руками, всё
>равно до него даже не доходила очередь - ядро падало ещё
>при своей инициализации.
>Уверен, ещё пара недель и эти грабли таки откопают. :(append = root=/dev/sda1 verbose vga=0 init=/bin/bash
И скрины в студию
>append = root=/dev/sda1 verbose vga=0 init=/bin/bashДелал (параметры перед загрузкой системы) - та же петрушка, не находит девайс (0,0) (у меня груб).
Что-то мне подсказывает, схалтурили кернелописцы - в 32 ревизии наверняка будет всё ОК.
>Что-то мне подсказывает, схалтурили кернелописцыА мне что-то подсказывает, что у Вас не GoboLinux, а руки крюки. Возьмите убунту уже, что ли, и оставьте kernel.org в покое.