Первый взгляд на ALTLinux 6.0 "Рабочая лошадь"

Некоторое время назад было известно что команда ALTLinux  вынашивает планы по созданию серверного дистрибутива Linux  со сроком поддержки 5 лет. Много скептицизма с тех пор вылилось на эту идею, но как говорится "собаки лают, караван идет", вот и разработчики выкатили 8 апреля первую альфу дистрибутива ALTLinux 6.0 Centaurus. Посмотри мельком что он из себя представляет.
Установка ничем особо не отличается от ALTLinux 5.0 Ковчег, в качестве вариантов установки множество ролей, минимальный вариант(отключив все роли) получается на 418мб (в реальности около 700мб).
Костяк дистрибутива:

• Linux-2.6.32
• Glibc-2.11.1
• Coreutils-8.4
• Util-linux-2.17.1
• GCC-4.1.2/4.3.2/4.4.3
• Python-2.6.5
• Perl-5.8.9
• OpenSSH-5.3p1
• Java-1.6.0-sun
• Bash-3.2.51
• Bind-9.36

Файловая система по-умолчанию ext3. Основной набор софта для LAMP на данный момент такой:

• apache-2.2.14
• php-5.2.13
• mysql-5.0.89
• vsftpd-2.2.2

Какой либо жесткой ориентированности на сервер у дистрибутива пока не замечено, на DVD  присутствует широкий набор софта:  и xorg-server-1.8, и blender, и gnome-2.28, и  openoffice, и еще куча всего.

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

Настройка точки доступа WIFI на OpenBSD

Есть рабочий шлюз на OpenBSD, понадобилось подключаться к нему по WIFI. Был в наличии PCI-адаптер TPLink на базе Atheros AR5212. Не лучший выбор для OpenBSD, однако системой определился:

ath0 at pci0 dev 15 function 0 "Atheros AR5212" rev 0x01: irq 4
ath0: AR2414 7.9 phy 4.5 rf2413 5.6, FCC2A*, address aa:bb:cc:dd:ee:ff

Смотрим поддерживаемые режимы работы данного адаптера в секции supported media:

ifconfig ath0 media

Почему то отсутствуют режимы IEEE 802.11g, но меня вполне устраивает:

media autoselect mode 11b mediaopt hostap

Значит можно попробовать настроить эту карту в режиме "точка доступа". Создадим файл /etc/hostname.ath0 следующего содержания:

up media autoselect description "WLAN" mediaopt hostap nwid "network" wpa wpaprotos wpa2 wpapsk `wpa-psk network mysupersecurekey`
inet 192.168.111.1 255.255.255.0

Запустим этот интерфейс и переведем его в режим отладки:

sh /etc/netstart ath0
ifconfig ath0 debug

Попробуем попинговать, посмотреть вывод dmesg и если не зависнем и никаких тревожных сообщений не увидим значит можно продолжить дальше. Что касательно этой карты, то в версиях OpenBSD младше 4.6 в режиме "точка доступа" ее лучше не использовать.
Настроим dhcpd (/etc/dhcpd.conf) на выдачу адресов подключающимся клиентам, например так:

option domain-name-servers 192.168.111.1;

subnet 192.168.111.0 netmask 255.255.255.0 {
option routers 192.168.111.1;
option ntp-servers 192.168.111.1;

range 192.168.111.32 192.168.111.127;

}

Подразумеваем что на этом же сервере запущен кэширующий DNS и сервер времени NTP. В файле /etc/dhcpd.interfaces перечислим интерфейсы, на которых будет слушать dhcpd, например только ath0, а также включим загрузку сервиса dhcpd при старте системы (dhcpd_flags="" в /etc/rc.conf.local или /etc/rc.conf).
В пакетном фильтре PF для интерфейса ath0 применим политику "все что не разрешено то запрещено", разрешим DHCP, NTP и NAT(ограничимся http и jabber) на одном интерфейсе, а также заблокируем доступ в некоторые сети подключенные к другим сетевым интерфейсам. Сделать это можно, например, следующим набором правил, который не стоит считать достаточным:

nat on $some_if from ($wifi_if:network) -> ($some_if:0)
block in on $wifi_if
block in quick on $wifi_if to ($other_if:network)
pass in quick on $wifi_if inet proto udp from ($wifi_if:network) to $wifi_if port { domain, ntp } keep state
pass in quick on $wifi_if inet proto udp from 255.255.255.255 port bootpc to $wifi_if port bootps keep state
pass in quick on $wifi_if inet proto icmp from ($wifi_if:network) icmp-type $icmp_types keep state
pass in quick on $wifi_if inet proto tcp from ($wifi_if:network) to !$wifi_if port { www, https, 5223, 5222 } modulate state

Уточним, что dns-серверу разрешено обрабатывать запросы из подсети wifi и запустим dhcpd.
Теперь можно пробовать подключаться. Подключение с Asus EEE PC 901 с wifi-картой Ralink и ОС Ubuntu Netbook Remix 9.10 прошло успешно. С коммуникатора HTC Diamond подключение прошло, адрес получен, однако дальше проблемы, tcpdump на сервере показал только обмен arp-запросами, однако времени разбираться нет за ненадобностью, главное что с ноутбуков подключается.

Видеокарта ATI и семь кругов ада

Как-то в воскресный день моя видеокарта GeForce 7600GT 256bit служившая мне верой и правдой не один год приказала долго жить. Встал вопрос о покупке новой. Игрульками я уже давно не увлекаюсь поэтому взор упал на бюджетные модели. Промозглая погода сделала свое дело и желания ехать куда-то за самой дешевой картой или прошвырнуться по комиссионкам не возникло. В ближайшем магазине менеджер на мою просьбу выписать самую дешевую видюху на PCI-E предложил мне RadeonHD 4650 и какую-то NVIDIA. Секундное колебанея в сторону NVIDIA угасло за мыслью что 2D на открытых дровах ATI работает нормально.

Втыкаю я этот Radeon в комп и первая мысль - а кто успокоит этого карлсона? Привычка к видюхе с пассивным охлаждение засела в подкорку. Ладно думаю, пока настрою. Всяких баек о глючных дровах ATI я не боюсь как истинный джентушник. Завел драйвера Catalyst-9.9 на linux-2.6.31.4, карлсон поутих, хоть и не завывает теперь, но все равно неприятно шумит. В xorg.conf пришлось создавать секцию Monitor, ибо само оно подефолту хотело 8bps цвет, а он еще и дровами не поддерживается. Стыдно товарищи ATI. Так glxgears показал 6600 fps, слабовато на фоне старенького geforce (9800 fps), ладно четр с этим 3D да и не бенчмарк это. В 2D все нормально,хотя иногда создается впечатление дискомфорта(проскакивают артефакты), с этим можно смириться. Видео в mplayer воспроизводится нормально без эффектов рассинхронизации кадров в динамических сценах. В общем драйвер для этой видюхи пригоден к употреблению.

Переходим на открытые дрова. Берем xf86-video-ati-6.12.4 и xf86-video-radeonhd-1.3.0. В 2D с обоими все замечательно, а вот видео нормально воспроизводит лишь radeonhd в режиме "xv - textuted video", драйвер же ati в зависимости от режима либо тормозит безбожно на полном экране (1680x1050) либо на динамических сценах присутствует эффект рассинхронизации. 3D на обоих софтовое. Получается что открытый драйвер для этой видюхи малопригоден.
Все ATI'шники ждут счастья с выходом ядра 2.6.32, в которое добавлены DRM модели из ветки x11-drm(которая в свою очередь объявлена законченной). Берем linux-2.6.32_rc5, текущий срез xf86-video-ati и mesa-7.6. В ядре включаем по-умолчанию "Kernel Mode Settings". Загружаем, фреймбуффер на родном разрешении производит впечатление, переключение между Xorg и консолью просто реактивное. Смотрим, появилось аппаратное 3D (по крайней мере так говорит glxinfo), glxgears выдал 2700 fps. Видео сели подобрать правильный модуль вывода работает нормально. 2D чисто по тестам работает нормально, а вот в реальной работе тормоза даже при переключении окон, перетаскивании и ресайзе. Если взять полноэкранный терминал на основе VTE, поставить ему истории много тысяч строк, сделать вывод dmesg, то таща быстро мышкой скролл, последний очень сильно за ней не будет поспевать. работать почти не возможно с таким 2D. Пробуем radeonhd и тут сюрприз - не хочет он заводиться с KMS (просто черный экран, хотя комп нормально выключается по ACPI-event). Перегружаем отключая KMS, radeonhd заводится, 3D есть, glxgears рапортует 2200 fps, однако в видео на динамических сценах в зависимости от модуля вывода становится заметен с той или иной степенью эффект вертикальной рассинхронизации; с 2D все в порядке. Запускаем драйвер ati без KMS - 3d есть, glxgears выдает 1600 fps но зато с 2D и видео все в порядке.

Однако главной проблемой текущих дров (а может БИОС данной карты) является неспособность усмирить карлсона, чтобы он хотя бы не выл так противно. Если драйвера научатся нормально управлять энергосбережением то комбинацию kernel-2.6.32-noKMS/ati-next_verison/mesa-7.6/xorg-1.6.5 можно считать более предпочтительной проприетарному драйверу для карт r600/r700(не беря во внимание игры и многомониторные конфигурации) а пока и Catalyst-9.9/linux-2.6.31.4 есть не просят.

Выкидываем XDM или Qingy

Многие наверно задумывались зачем вообще нужны эти дисплейные менеджеры (X Display Manager) когда в большинстве случаев для простого пользователя всего-то от них что и требуется выбрать сессию да ввести имя и пароль. При этом на фоне борьбы за каждую секунду загрузки системы лишний запуск/перезапуск X'ов какбы совсем не к месту. Поэтому если от XDM ничего выдающегося не надо можно его смело выкинуть и установить Qingy.
Qingy - это замена для getty на определенном этапе, которая использует Framebuffer и DirectFB для вывода графики. Вместо традиционного приглашения getty ввести логин а затем пароль на экране будет некая замена XDM но на основе DirectFB при этом без всяких X'ов, все что требуется это устройство framebuffer.
Программа хорошо конфигурируема, вот некоторые возможности:

• Поддерживает темы, их изготовление довольно простое занятие
• Поддерживает как X-сессии так и текстовую консоль
• Запустить более одной X-сессии
• Хранитель экрана
  
• Автоматический вход в систему
  

Более подробно с возможностями можно ознакомиться на странице разработчика. Что, понравилось так это возможность запуска X-сессии в тойже консоли в которой зарегистрировался(возможен и традиционный режим). Получается по сессии на консоль. Также можно, например, для 1 и 2 консоли прописать Qingy, а для остальных оставить стандартный agetty. Примеры уже готовых тем можно посмотреть тут, скачать пакет с этими темами тут.
Установка проста до безобразия и подробна описана в FAQ на сайте разработчика. Я устанавливал на Gentoo, процесс установки описан. Если коротко то необходимо сделать следующее:

1. устанавливаем dev-libs/DirectFB (-X +fbdev) и sys-apps/qingy (+directfb)
2. берем fbset и его вывод записываем в /etc/fb.modes, также в /etc/directfbrc указываем этот режим
   
3. меняет в inittab на нужных нам консолях agetty на qingy
4. в конфиге qingy указываем нужную тему (мне понравились matrix и vendetta3)
5. отключаем XDM и перезагружаемся для верности

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

Обзор свежей сборки Midori

Сегодня так уж вышло, что я решил потратить пару тройку часов на обновление домашней системы (а Gentoo опасно долго не обновлять, благо 2.5 месяца это не очень большой срок). Помимо всего прочего я заметил что midori и свежий webkit-gtk замаскированы в портежах ссылаясь на отсутсвие свежей libsoup. Ага, значит наконецто теперь он будет куки сохранять, стоит попробовать. Отсутствие чего-либо в Gentoo это не проблема.

И так, берем www-client/midori-9999 и net-libs/libsoup-2.26.0.9 из моего оверлея FreshGen, размаскируем из основного дерева портежей net-libs/webkit-gtk-0_p42162 (наконец-то они додумались убрать зависимость от gnome-vfs которая заключалась лишь в imclude и не более) и установим со следующим флагами: pango soup sqlite svg xslt sqlite. В дополнении к этому поставим www-plugins/gnash-0.8.6_p20090410 с флагами agg cairo ffmpeg gtk neon nsplugin opengl parallel speex из gnash-cvs.

После того как все это соберется и запустится у тех кто смотрел midori 3-5 месяцев назад будет восторг - теперь гадкий утенок из демки для webkit'а превратился в какой-никакой а браузер.

Основные нововведения:

• причесали интерфейс


• поддерживается сохранение cookie в кэше


• поддерживается загрузка файлов (пока только "Загрузить объект" из контекстного меню)


• появились расширения, одно из них "Цветные вкладки" кажется оригинальным

В целом не плохо: скорость работы радует более чем, обилие рекламы и flash'а на странице не вызывает торможения в прокрутке и перемещении по вкладкам, удобно включать/отключать javascript, flash и изображения. Если прикинуться Safari то Gmail с его "Full View" работает нормально. Не хватает только сохранения сессий, AdBlock (который при желании можно написать в виде расширения на Lua) и NoScript(расширение, которое FireFox делает недосягаемым для конкурентов в области удобства блокирования javascript и защиты от всяких "махинаций" в том числе на уровне CSS и XSS).

Тестирование Intel GMA 900 на EEE PC 901

Продолжаю серию тестов нетбука Asus EEE PC 901. В предыдущей заметке написано как завести все это железо в рамках Gentoo Linux. Теперь самое время провести тесты видеокарты, результаты которых должны быть интересны в свете последних событий в развитии драйвера xf86-video-intel и интеграции в него новых фитч, повышающих его производительность и стабильность. Наибольший интерес представляет поддержка системы управления памятью GEM (Graphics Execution Manager), ибо уже подоспело ядро linux-2.6.28 и вполне юзабельным стал разрабатываемый xorg-server-1.6.0.
И так преступим. Установим xorg-x11-7.4 ( xf86-video-intel-2.5.1-r1, xf86-input-synaptics-0.99.3 и xorg-server-1.5.3), проконтролировав что установлены USE-флаги dri,hal,xv,xvmc, убран флаг SSE2 дабы не обновлять gcc до 4.3 и glibc до 2.9, а также устройства intel, vesa, synaptics, evdev, keyboard,mouse . Сразу стоит оговориться, что на сегодня по части производительности все что выше xorg-server-1.3 оставляет желать лучшего, но так как все-таки нетбук предъявляет дополнительные требования по функционалу, например, подключение устройств ввода/вывода "налету", придется закрыть на это глаза.
Убеждаемся что syslog-ng, acpid, sshd и hald будут стартовать автоматом при загрузке и перезагружаем подопытного для чистоты эксперимента. Заходим по ssh пользователем root и стратуем с пустым xorg.conf- starx. Смотрим что нам говорят glxinfo и glxgears: failed to initialize TTM buffer и direct rendering: Yes, 60FPS всреднем (что значит включен VSinc). Каких либо серьезных тестов проводить не буду, ибо уже 100 раз тестировалось. Мне главное убедиться, что от всех этих новых штучек будет прок в простых задачах: 2D, Video, простые OpenGL игры.
Теперь выполним более реальный тест, оценив производительность тулкита GTK. Сразу оговорюсь, для отрисовки шрифтов будут использоваться патчи из оверлея bobrik-cleartype, дабы на LCD шрифты смотрелись не так страшно (особенно когда есть с чем сравнивать). Устанавливаем gtkperf-0.4, gtk+-2.12.11, cairo-1.8.6-r1(glitz opengl) и запускаем очередную серию тестов. Получаем Total time: 16.86. Крутим опции драйвера видюхи следующим образом:

Section "Device"
Identifier "Configured Video Device"
Option "AccelMethod" "UXA"
Option "Tiling" "No"
EndSection

Все, запускаем опять gtkperf и видиим. Total time: 303.83. В целом все медленнее незначительно, но львиная доля уходит на:

GtkDrawingArea - Lines - time: 264.64
GtkDrawingArea - Circles - time: 10.72
GtkDrawingArea - Text - time: 12.25

Что то не ладно с новым методом акселерации (UXA), возможно надо mesa и xorg-server посвежее. Теперь посмотрим на поддержку 3D. Серьезные тесты гонять нет смысла хотябы потому, что это железо не предназначено для таких задач. Ограничимся запуском игрушки games-action/extreme-tuxracer. Пока не будем шаманить с 3D (например, забудем о force_comptex_s3tc.so), посотмрим дефолтовую производительность. Как оказалось смотреть не начто: в full-screen при 1024x600 оно не играбельно. Ну что же, если брать релизные версии софта, то Intel GMA900 не годится для игровых приложений, разве только для ускорения видео и Compiz. Скорее всего тут где-то что-то не так, но большого желания искать узкое место нет, лучше посотмреть что ожидается в следующем xorg-server, а вместе с ним и драйвер 2.6, GEM, обновленный libdrm и ядро со свежим DRM-модулем.

Добавим оверлей X11 и возьмем от туда следующие компоненты, попутно обновятся pixman и randr:

x11-proto/inputproto-9999
x11-libs/libdrm-9999
media-libs/mesa-9999
x11-base/xorg-server-9999
x11-drivers/xf86-video-intel-9999
x11-drivers/xf86-input-mouse-9999
x11-drivers/xf86-input-keyboard-9999
x11-drivers/xf86-input-evdev-9999
x11-drivers/xf86-input-synaptics-9999
x11-proto/dri2proto-9999

Опционально можно обновить и эти библиотеки(я не стал пробовать), однако есть риск словить нестыковки с другими библиотеками такими как cairo и gtk :

x11-proto/xproto-9999
x11-proto/xcb-proto-9999
x11-libs/libxcb-9999
x11-libs/libX11-9999

Смотрим на результаты gtkperf: Total time: 15.77. Уже не плохо. Включаем метод акселерации графики UXA(tiling теперь не нужно отключать) и получаем первую прибавку: glxgears выдает 259FPS. Походу Vsync теперь отключен в Mesa (чето такое я видел в лога репозитария на тему еще недопиленого UXA). А вот gtkperf дает осечку, хотя не такую страшную: Total time: 18.21. Кстати стоит заметить отсутсвие ругани на TTM buffer, значит GEM работает. Также судя по логам DRI2 тоже работает. Запустим нашу игру etracer: вау!, в 2 раза быстрее, теперь выдает 3FPS вместо прежних 1.5FPS. Вот они обещанные 50%, :) надо будет подумать может где загвоздка, но пока это не суть важно. Можно конечно попробовать снапшот ядра drm-intel. Насколько я понял, в ветке drm-intel-next ведутся основные разработки по необходимым нам модулям drm. Однако посмотрел логи, серьезных изменеий относительно производительности я не заметил, только фиксы и поддержка kernel-videomodeset.

Ну пожалуй до полной картины осталось протестировать воспроизведение видео. О наличи в каком либо плеере/библиотеки/драйвере аппаратной поддержки декодирования видео(как например у nvidia) на видюхах Intel я не знаю(). Поэтому сделаю просто: установлю mplayer-9999 из оверлея berkano. i8x0 xvmc у меня не заработало, что бы я не прописывал в /etc/X11/XvMCConfig: libIntelXvMC.so.1 или libI810XvMC.so.1:

localhost ~ # cat /var/log/Xorg.0.log | grep XvMC
(**) intel(0): Option "XvMC" "true"
(==) intel(0): Intel XvMC decoder disabled

Значит сломано до сих пор или както по другому включается(когда включится то можно будет проверить на xine-lib). Теперь пробуем различные видео записи(с оглядкой что просмотр идет по 100мбит сети). В качестве примеров несколько файлов наугад: big_buck_bunny_1080p_surround.avi (1Gb), Stargate.The.Ark.Of.Truth.2008.1080p.HDTV.x264-hV_RUS_ENG.mkv (7Gb), и несколько простых фильмов. Без Direct Rendering (опция -dr, не путать с DRI) смотреть почти все(заисключением широкоэкранных фильмов низкого разрешения) некомофртно: заметны дерганья картинки во многих сценах. Самый быстрый(и единственный комофртный) вывод видео через Xvideo. OpenGL и особенно Textured video(gl2) в данном случае оказались мало пригодны для просмотра тоже. Особенно разницу видно на "Звездных вратах": на XVideo идет дерганое видео и звук, на GL и GL2 все начинает тормозить начиная с заставки "со львом", сам фильм же уже нельзя назвать дерганый, он уже рваный. Да и вывод через gl/gl2 не сильно разгружает проц: от 5 до 15% разницы.

Подитожу выше сказанное: большого толка от этих карточек с ускорением нет - уж слишком занижены частоты и медленный обвяз. XvMC не понятно как включать, возможно оно не хочет заводиться с DRI2. Вцелом, драйвер intel-2.5 поправил баги накопившиеся, какой либо эффект от UXA в сравнении EXA в области 2D особо не наблюдается, даже наооборот. Получается, если не нужно 3D вообще, то можно смело забить на GEM, по части Xvideo это мало чем поможет. Тут два выбора: если необходим функлионал XRandR, XOrg.Hotplug то нужно смотреть в сторону xorg-server-1.5/1.6 и всех этих плюшек, в противном случае смело откатываться на xorg-server-1.3 и не париться. Как мне кажется, нужно подождать первых ласточек 2.6.29, к тому времени в нем возможно улучшат Intel DRM, да и libdrm, intel-2.6 и xorg-server-1.6 возможно подшаманят.

Свой linux на EEE PC 901

Отгремели новогодние салюты, улицы опустели, народ начал отдыхать от праздников. Я решил тоже посвоему отдохнуть, достав месяц лежавший новенький небук ASUS EEE PC 901 с чемто нечто неюзабельным под названием Xandros.
Идея была изначально прикрутить к нему Debian так как в рамках проекта DebianEeePC идет активная работа, однако лень взяла свое и чисто из академического интереса я начал пробовать на нем Gentoo, решив для начала потестировать на нем linux-2.6.28.
Дабы не утруждать себя занудными процессами компиляции на Intel Atom, скачал stage3-i686-20081224.tar.bz2, распаковал его на домашнем компе, "зачрутился" туда, добавил в make.conf оптимизации компилятора(march=prescott и -fomit-frame-pointer), подкрутил USE-флаги, размаскировал linux-headers-2.6.28-r1 и gentoo-sources-2.6.28 и отправил в недолгий путь emerge -vuND @system.
Теперь самое время подумать о загрузке всего этого пробного добра на малыше EEE PC. RSinc'акть rootfs после каждого чиха на него как-то не сруки, поэтому ставим на домашний комп net-misc/dhcp, net-ftp/tftp-hpa и net-fs/nfs-utils-1.1.4 что позволит экспортировать rootfs по сети через NFSv3, а также грузить ядро по сети через PXE.
Теперь собираем ядро 2.6.28 в подоспевшем chroot'е для EEE PC 901. Ключевые моменты конфига ядра таковы: --->

1. Processor family (Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon)
   
2. Symmetric multi-processing support и SMT (Hyperthreading) scheduler support (для BIOS'ов с поддержкой Hyperthreading)
3. Не включаем в ACPI ASUS/Medion Laptop Extras
4. PCI Express support и модулем PCI Express Hotplug driver
5. Networking support--->Networking options--->IP: kernel level autoconfiguration--->IP: DHCP support
   
6. Все протоколы для bluetooth и драйвер HCI USB driver тамже
7. Для wifi Generic IEEE 802.11 Networking Stack (mac80211) и сопутствующие опции
8. RF switch subsystem support и Input layer to RF switch connector
9. В Device Drivers: Misc devices--->Eee PC Hotkey Driver (данная опция появится после включения некоторых нежеследующих пунктов), Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support, Atheros L1E Gigabit Ethernet support, Wireless LAN (IEEE 802.11), модулем Ralink driver support на всякий случай,
   
10. Input device support---> Mice---> PS/2 mouse---> Elantech PS/2 protocol extension
11. I2C support --->Intel 82801 (ICH)
12. Hardware Monitoring support модулем
13. Video For Linux--->Enable Video For Linux API 1 compatible Layer модулем, и тутже V4L USB devices--->USB Video Class (UVC)--->UVC input events device support
14. Direct Rendering Manager--->i915 driver
15. Backlight & LCD device support--->Lowlevel LCD controls и Lowlevel Backlight controls
16. Framebuffer Console support и Support for frame buffer devices--->Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support
17. Модулями ALSA и Intel HD Audio (пока не понтно о полной поддержке этой версией, например по части микрофонов)
18. Generic HID support и USB Human Interface Device
19. USB модулем, EHCI, UHCI, USB selective suspend/resume and wakeup, The shared table of common (or usual) storage devices(и запомнить об этом на будущее когда тестировать кардридер)
20. LED Support, Real Time Clock--->PC-style 'CMOS'
21. В ядро NFS client support--->NFS client support for NFS version 3 и Root file system on NFS, отключить обязательно Register local RPC services via rpcbind v4 дабы не словить проблему на 2.6.28.

Вот общий конфиг ядра, который будет грузиться на нетбуке. Полный рабочий конфиг, как и некоторые другие лежат по ссылке в архиве абзацем ниже. Также там есть патч для ядра, который решает проблему невозможности включения bluetooth.
Теперь самое время настроить удаленную загрузку по сети. Настраиваем DHCP, чтобы тот отавал IP из диапазона(у меня привязки к MAC нет, так по dhcp получает IP только netbook) и отадвал опции root-path на nfs с нашим chroot'ом и параметр filename на загрузчик pxelinux.0. Теперь настраивает tftp-server, я в конфиге указал корень на /var/tftp, положил туда ядро скомпиленное нами, pxelinux.0 и pxelinux.cfg с единым конфигом для всех. Самым вредным оказался nfsd, точнее баг в 2.6.28 ядре: необходимо чтобы опция Register local RPC services via rpcbind v4 была отключена (как впрочем на всякий случай и все остальны касательно ACL, NFSv4 и авторизации). Все, теперь экспортируем наш chroot под видом например таким: /mnt/hd1 192.168.2.20(sync,rw,no_root_squash,no_all_squash). Все сетевая загрузка готова. Архив с конфигами для тех кто плавает в этом вопросе тут.
Тут возникает проблема: baselaout не приспособлен для корня на nfs, поправить это не так сложно, но всетаки проще поставить baselayout2, отказаться от паралельной загрузки сервисов(что по умолчанию) и сразу ядру при загрузке по сети передавать что корень доступен на rw.
В результате получаем рабочую систему для тестирования железа и обкатки скриптов, wifi итд с консоли EEEPC(или по ssh), а также chroot на рабочем компе, в котором можно находится паралельно и ставить всеь необходимый софт без оглядки на ущербность проца.
Теперь потестируем работоспособность железа. Дрова на беспроводную карту(в моем случае это не atheros) за отсутствием их в ядре берем из оверлея arcon - net-wireless/ralink-rt2860. Прописываем в /etc/conf.d/modules автоматическую загрузку модуля pciehp, в /etc/modprobe.d/pciehp пишем options pciehp pciehp_force=1 и делаем update-modules. Устанавливаем sys-power/acpid. Все, перезагружаемся. Наблюдаем очередной сюприз в baselayout, как uevets думает некоторое время и в ключает без особой просьбы bluetooth и wifi. Убеждаемся что модуль ядра pciehp и eeepc_laptop подгружены. Если нет, то надо думать где ошиблись. Ставим sys-apps/pciutils и sys-apps/usbutils.
Теперь, чтобы включать/выключать wifi и bluetooth, смотрим в /sys/class/rfkill/rfkillX/name кто есть кто и посылаем туда 1 или 0 соотвественно(echo 0 > /sys/class/rfkill/rfkill0/state). С камерой маленько по другому но суть таже: echo 1 > /sys/devices/platform/eeepc/camera. После этих манипуляция можно при помощи нехитрых команд lspci, lsusb, dmesg, lsmod убедиться что устройства появляются-пропадают. Убедится в работоспособности звука легко, пока только особо не разбирался почему микшер не показывает регулировки для микровофона. До кардридера пока руки не дошли.
Следующим шагом будет приведение к 2.6.28- и gentoo-особеностям скриптов из серии eeepc-acpi-scripts а также тестирования нового драйвера x11-drivers/xf86-video-intel с mesa из свежего снапшота на предмет выявления какого-либо значимого ускорения от GEM. Также интересно выглядит перспектива потестить новый xf86-input-synaptics-0.99.3 на предмет поддержки каких либо особенностей родного драйвера для тачпада. На соновании чего можно будет сделать вывод - стоит ли писать скрипт для генерации из gentoo-chroot образа без всяких dev-штучек для EEEPC со всякими "извращенно-эффективными" файловыми системами/разделами или же затраты на его создание перекроют затраты сил
на перетаксивание и адаптацию и устаканивание в debian lenny свежих X.org, быстрый parallel-init, свежее ядро, что в перспективе дальнейше работы со всем этим не кажется столь радужным.