Выгрузка модулей перед переходом системы в спящий режим

На своей системе (gentoo) для ждущего и спящего режима использую pm-utils. Столкнулся с проблемой: если перед уходом в спящий режим, к ноутбуку подключена мышь, а потом попытаться "проснуться" без мыши, то проснутся не получится, система висит. На просторах интернета найдено решение: перед уходом в спящий режим необходимо выгрузить модули ядра этих устройств.Для pm-utils это делается путем создания файла в  

/etc/pm/config.d/

И добавлением в него в переменную SYSPEND_MODULES списка выгружаемых модулей
У меня он принял следующий вид:

SYSPEND_MODULES="usbhid ehci_hcd uhci_hcd usbcore"

Теперь спячку система благополучно переносит независимо от состояния мыши (подключена или нет)

Замена матрицы на asus eeepc 900.

Так уж получилось расколоть матрицу нетбука. Следовательно, исходная задача: замена матрицы на нетбуке eeepc900.

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

Затем начинается самое интересное: снятие с петель этой самой половинки крышки. Хочу подтвердить, что в вики на eee-pc абсолютно точно указано, что для того что бы снять матрицу, весь нетбук можно не разбирать. Достаточно долго вертелся я вокруг него, но потом кое-как снял ее. На снимке ниже: коварные петли

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

Прикручиваем эти штуки к новой матрице, подключаем шлеф, прикручиваем матрицу к крышке.
Затем,в моем случае, для меня было проще доразобрать нетбук полностью чем, плясать с крышкой, пытаясь ее посадить на свое место (ту часть крышки, что закрывает петли, не получилось затолкать на свое место, я решил что уж лучше доразобрать, чем потом клеить сломанную крышку). Дальнейшая же разборка вполне соответствует инструкциям с вики.Отмечу лишь, что нужно соблюдать осторожность при поднятии верхней половинки нижней крышки. Обязательно отключить клаву, точпад. Собственно получится следующее:

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

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

Результатом остался доволен, все работает, это так сказать второе рождение данного нетбука)

Перенос последнего коммита из одной ветки в другую

В ходе использования и одновременного изучения системы контроля версий mercurial допустил ошибку:
имелось 2 branch'a:
default и next.
Не замеча, что текущим является branch next, я закоммител изменени, нужные мне в default.
Собственно задача сводится к откату последнего коммита из бранча next, и коммита этих изменений в branch default.
На #mercurial мне подсказали решение:

hg update next
hg export tip > ../last-commit.diff
hg rollback
hg update default
hg import ../last-commit.diff

Итак: hg update - обновление рабочей версии до нужного branch'a. hg export - экспортируем в файл изменения последнего коммита. hg rollback - откат последнего коммита, ну и hg import это импорт изменений в репозиторий.

Все бы ничего, но hg import ругается на невозможность применения изменений. А вся причина в том, что последний коммит, тот что у нас в файле, накладывается на файлы, версии которых лежат в другом бранче. В этом нет ничего страшного. для этого придется закоммитить все версии этих измененный файлов до версий из другой ветки. т.е. делаем hg revert до нужной версии, и коммитим в первом бранче. После этого import пройдет без проблем.