Наутилус терпеть не могу, но не смотря на это всё ещё помню как запускал раньше. Специально для проверки поставил эту бяку, попробовал — и сейчас в норме :-/
nautilus --no-desktop -n ~

Компиз-эмеральд с какими опциями запускаешь?
ck-launch-session \
compiz  --replace ccp

что - вот, прям так и не глючит?
Ты не поверишь :-/

P.S. люблю-не люблю наутилус — мои заботы. Мнения не навязываю.
Но он нормально работает с cairo.

Кстати, возможно, пригодится и такая команда в автозагрузке - подгрузка наутилуса без создания окон
nautilus -n --no-desktop
Работаю с cairo давным давно. Приколов нет. Летает, радует глаз.
awn — слабенький до cairo явно не дотягивает.
ABI class: X.Org Video Driver, version 8.0
(EE) module ABI major version (8) doesn't match the server's version (9)
(II) UnloadModule: “ati”
Текущая проблема вообще-т в xf86-video-ati

Вы таки гуглили по этому сообщению?
Не верю. И ясен пень, что пересобирать надо все драйверы x. А не только dri. Я вам, сударь, направление указал, а вы ленитесь :-/
Ответ находится в рассылке xorg-driver-ati. http://www.mail-archive.com/xorg-driver … 15952.html

А за одно и горячий фикс держите. В каких-то версиях косячок при сборке драйвера вылетает. надо удалить пару строк: http://www.mail-archive.com/xorg-driver … 15965.html

 pacman -Q | grep xf86- 
почти наверняка укажет абсолютно всё, что требуется пересобирать.
greenif
Но вто столкнулся с следующей проблемой:
X -configure
Говорит:
/var/log/Xorg.0.log
Я понимаю что ключевой фразой здесь являеться
(EE) module ABI major version (8) doesn't match the server's version (9)

И что верися ABI не совпадает с версией Xorg.

Но вот что такое ABI и где взять его предыдущую версию?
Я так понял что это пакет xf86-video-ati-git?

Даже если не знать изначально, то вбив ошибку в гугл можно получить ответ:
драйверы xorg необходимо собирать после установки xorg. Отсюда следует решение - потребуется пересобрать видеодрайвер. В данном случае поможет повторный запуск yaourt ati-dri-git.

Кроме того, установите input-evdev из git aur/xf86-input-evdev-git
Рабочая машинка.
[[email protected] ~]$ sudo find /var | wc -l
33458
[[email protected] ~]$ sudo du -s /var
1654340	/var
[[email protected] ~]$ find /var/cache/pacman | wc -l
838
[[email protected] ~]$ du -s /var/cache/pacman
1434236	/var/cache/pacman

Где ж тут много мелких файлов-то в /var? Без кэша пакмана 32 тыщи файлов в сумме на 200 метров. не такие уж и маленькие, и не так уж и много.

Мой выбор - одна система для /boot, одна система корня, отдельный дом. По моим критериям хватает, да и разделы плодить не приходится.

$df -h
/dev/sda2              28G  7,1G   21G  27% /
/dev/sda1             471M  260M  212M  56% /boot
/dev/sda5              23G   18G  5,1G  79% /home
udev                   10M  292K  9,8M   3% /dev
shm                  1003M  912K 1002M   1% /dev/shm
none                 1003M  8,0K 1003M   1% /tmp
none                 1003M  4,3M  999M   1% /var/tmp

Но, если всё-таки решил делить корень на части - заметь, что
Основное место ест /usr и /var/cache/pacman (6.9Gb из 7.1 занятых). Без них корень и на 300MiB уместиться. Но нужно ли это деление?
У тебя что, сервер с логами, которые могут сожрать место? Или парк и usr можно монтировать по nfs?

$sudo du -xh --max-depth=1 /
5,9M	/bin
4,0K	/mnt
1000K	/opt
0	/proc
7,5M	/sbin
13M	/root
0	/tmp
5,4M	/etc
101M	/lib
80K	/media
5,3G	/usr
16K	/lost+found
1,0K	/boot
0	/dev
4,0K	/lib64
4,0K	/home
16K	/srv
1,6G	/var
0	/sys
7,0G	/

P.S. Мой раздел /usr разжирел на лишние 1.4GiB. Виновник я сам - исходники ядра гитовские в /usr/src/linux-2.6-stable держу да сборку в /usr/src/build-*
du -hs /usr/src/linux-2.6-stable/
869M	/usr/src/linux-2.6-stable/
du -hs /usr/src/build-k3-aufs/
551M	/usr/src/build-k3-aufs
milgoff
В частности какая наиболее лучшая последовательность монтирования разделов(/boot, /, /var, /usr, /tmp, /home… swap)?
Принципиальной разницы нет, по скольку запуск демонов и прочего происходит уже после монтирования фс. Но, думаю, что такой порядок уместен:
/boot монтировать вовсе не обязательно - параметр noauto поможет в этом
/ - ясное дело - основа
/var - изменяемое, в том числе и логи
/tmp и /var/tmp - хлам. Сам использую tmpfs для них, ибо это потенциальная мусорка.
/usr - различный софт
/home - лишь бы до входа пользователей

Тот же своп раздел на дебиане вообще не использовался или таки оставить гиг на всякий пожарный(оперативки 2 Гб)?
да, обязательно надо оставить. и не гиг, а как минимум столько же, сколько и оперативки. Кроме отказоустойчивости в «экстренных случаях» есть ещё и hibernate. Возможно, надумаешь использовать.

По поводу файловых систем, имхо, лучшие тесты свои собственные.
Я был долго на reiserfs, потом на xfs, перешёл к ext4. Принципиальной разницы при работе с кучей мелких файлов (сотни и тысячи до 50кб - различные исходники) на глаз не видно - кэширование даёт о себе знать. При работе с большими файлами у меня, почему-т ext4 получается шустрее. Возможно причина «одинаковости» в -noatime, с которым я всё время монтирую /home.

reiserfs на десктопе - не всегда лучший выбор - подтормаживает на средних и крупных файлах. Но, повторяю: лучший выбор фс, сделаешь только сам.
погоняй тесты имитирующие твою обычную работу. Таскаешь крупные файлы - dd if=/dev/zero of=./5GB bs=1MB count=5KB, мелкие? bs=5kb count=10.
Много читаешь? ls -laf .* и подобное. Лови примерчик того, как один из гентушников выбирал фс для раздела /usr/portage, в котором оч много мелких файлов (файлов сборки .ebuild) и относительно мало крупных - заархивированных сырцов.

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

milgoff
Использую ноут, т.е. выключение света не критично.
Верно, но возможна ситуация с зависонами. Как ни крути - риск есть.

milgoff
Потом, насколько вообще целесообразно выделять /tmp и /usr. А если и выделять, то сколько места им отводить, и сколько для оставить для /root. Да так, чтобы с запасом, а не в притык.
/tmp и /var/tmp рекомендую выкидывать на tmpfs. То есть место не выделять - пусть в озу висит. Если потребуются много места для временных файлов, имхо, лучше добавить свап-раздел побольше.

/usr на дексктопе, имхо, выкидывать в отдельный раздел не обязательно. Как минимум упрощается бекап-восстановление. Сам использую скриптик, подобную последовательность команд, получая на выходе архив системы и архив загрузочного раздела.

mkdir /tmp/root-mirror && mount - bind / /tmp/root-mirror && myBackuper /tmp/root-mirror && umount /tmp/root-mirror
 mount /boot && myBackuper /boot && umount /boot




моя разбивка. fs ext3, ext4
/dev/sda:
/boot 480Mb ext3 (ядра, бекап модулей, образ resquecd)
/ 28Gb, ext4, занято 7
/home - ext4
/tmp tmpfs
/var/tmp tmpfs

/dev/sdb
unmounted /dev/sdb1 - актуальная копия /boot с основного винта
/home/backups ext4 (сквоши /, /boot и /home которые можно в случае чего восстановить с помощью rescuecd с /boot либо /dev/sdb1 )

при этом местами использую aufs (например, ~/coder/abs = /var/abs=ro + ~/coder/abs=rw)


Но, в общем — лучше тебя твои принципы работы никто не знает. И решение принимать тебе.
echolife
Сейчас попробую дать права на /home/echo/.config/compiz/fusion-icon
Почему это только на compiz? принудительно верни права пользователю на его домашний каталог. хД

sudo chown -R echo:echo /home/echo
echolife
Честно не очень понятно. Понятно только вот это:
/usr/lib/compizconfig/backends/libgconf.so: cannot open shared object file: No such file or directory.
Но почем тогда все работает под root?

Не туда смотришь )
IOError: [Errno 13] Permission denied: '/home/echo/.config/compiz/fusion-icon'
Держу пари, что ls -lad /home/echo/.config/compiz/fusion-ico укажет, что хозяин не echo, а root, а возможно даже и раньше рутовские владения пошли )
Риторический вопрос: а ты уже знаешь, чем отличается «su» от «su -»?
vadik, абсолютно согласен с тем, что ссылочка полезна для ознакомления. Но, в данном конкретном случае сидеть на старых иксах, имхо, нелепо.
Побаловался чуть с кедами. вот что получилось.

Compiz, cairo-dock, kde 4.5.2