Напишите чуть больше про тормоза tt-rss, плиз.
А то я, начитавшись обзора self-хостед RSS ридеров на хабре, уже почти собрался его ставить.

Официальный мануал по удалению всего
http://wiki.winehq.org/FAQ#head-8a17a13a8a4cda9e12e24a1ad4e1b1aaf043d581

Ещё в ~/.local/share/mime/packages оказывается, мусорит.

Я обдумывал подобные идеи, но пришёл к выводу, что сотрудники магазина, скорее всего, крайне негативно отнесутся к таким действиям.

flock -n /tmp/MyScript.lock -c MyScript.sh || kdialog --error 'Already running'

Ссылки с фотографий ведут непонятно куда, а не на полноразмерные версии.

Всё-таки не совсем достаточно. От игры могут остаться *desktop файлы в ~/.local/share/applications и иконки в ~/.local/share/icons

ssid=`/sbin/iwconfig wlan0 | awk '/ESSID/{print $4}' | sed -s 's/ESSID://'`

Плохой способ. Совсем далеко не факт, что ядро успеет сбросить дисковые буферы, прежде чем рухнуть.

+1 за Knoppix пятилетней давности.

Вот странно, что ни автор этого вопроса-топика, ни автор на хабре не догадались проанализировать, что же там тормозит, прежде чем колдовать над настройками. А ведь так просто:
ssh -v

Или даже вот так
strace -ttt -e trace=write ssh -v

mc не умею. Сам бы делал так
vim -O scp://user@somehost/filepath scp://user@anotherhost/anotherfilepath
И там уж средствами вима хоть обкопируйся. Ну может поддержку мыши сначала нужно будет включить
:set mouse+=a

http://welinux.ru/post/4636/

Скажем сохраняем корень:
mkdir /tmp/tmpmount
mount --bind / /tmp/tmpmount
cd /tmp/tmpmount
tar -czf /media/EXTERNALHDD/root.tar.gz *
И так для каждого раздела.

Кроме того, есть мнение, что сохранять данные безопаснее загрузившись с LiveCD/LiveUSB.

Кстати да, я тоже пару недель назад у себя с удивлением заметил, что bash зачем-то грузит /usr/lib/gconv/KOI8-R.so. Попробовал переименовать, чтобы посмотреть, на что ругнётся - не ругнулся o_O Переименовал обратно - больше не грузит o_O. Так и не понял WTF.

файлуха смонтирована с noatime?

Как насчёт проанализировать с помощью bootchart?

На своём Palm TX пробовал грузиться в чужие сборки на основе gpe и opie. Впечатляет, но плотно экспериментировать и тем более пытаться перелезть счёл нецелесообразным. В основном из-за того, что у палма к тому моменту стал сильно сбоить дигитайзер, калибровка могла бы помочь, если бы проводилась не менее чем по десятку точек. PalmOS замечательно рулится хардварными кнопками, а если и возникает нужда тыкать в элементы на экране, то они относительно крупные, запомнив, где и насколько экран искажает координаты нажатия, вполне можно жить, а gpe/opie контролы мелкотравчатые и хардварными стрелками не особо порулишь. Кроме того, не сообразил, где брать софт. Репозиториев не нашёл (если их вообще кто-то организовывал под мою платформу), а магия кросскомпиляции мною до сих пор не освоена, в условиях глючного экрана и пробовать её освоить не пытался.

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

Поправка для п.2: сдампить нужно не хард целиком, а каждый раздел в отдельный файл.

Не получится. Идея в том, чтобы хранился дамп в сжатом виде, а для lvm'а был доступен в несжатом виде как обычный block device.

Если образ хотя бы одного харда хорошо жмётся, то проблема решаема.

1. Организуем на ноуте файлуху с transparent compression (ZFS / Btrfs)
2. Дампим на неё хард с помощью dd (молимся всем богам, чтобы влезло)
3. Собираем LVM из второго харда и файла дампа первого (нужно будет поправить lvm.conf, чтобы vgchange -ay искал physical volume'ы и в той папке, куда сохранён дамп)

Если просто так дамп не влезает, монтируем что можно с LVM'а одно харда и затираем как можно больше всего ноликами.

Ещё идея: подключить файловую систему со второго ноутбука через сеть и объединить свободное место на них тем же LVM'ом.

Как уже сказали выше, в венде под виртуалкой игрушки работают ещё хуже, чем в Wine. Предлагаю снять образ раздела с виндой (видимо, предварительно его уменьшив), а потом, если уж возникнет такая необходимость, уменьшить линуксовые разделы и воткнуть в освободившееся место раздел с виндой обратно. Clonezilla в помощь, я, впрочем, её не трогал, предпочитаю более низкоуровневые методы.

Занятно, я когда писал предыдущий комментарий во многом исходил из того, что unset GREP_OPTIONS в скриптах не встречается, даже проверил, сделав grep -iR GREP_OPTIONS /etc/rc.d.

1. Да вот как раз примерно к тому, на что вы наткнулись, и приводит:$ for coloring in --color={always,auto}; do echo 'abcdef' | grep $coloring bcd | grep def; done
abcdefЕсли бы не приводило, то abcdef напечаталось 2 раза
2. Упоминая про дефолтное содержимое ~/.bashrc я хотел сказать, что гуру считают раскрашивание через alias более правильным. Плохо выразился.
3. Кроме ощущения, что "это как-то не совсем правильно", у меня нет оснований утверждать, что сорсинг ~/.bashrc для иксовых прог - баг.

Знаете, это не бага, а сочетание не совсем корректных конфигов.

1. Выставляя color=always надо понимать, к чему это вообще может приводить
2. Стандартный убунтовый ~/.bashrc реализует расцвечивание grep'а через alias grep='grep --color=auto'При задании --color=always через alias проблема бы не возникла
3. Полагаю, GREP_OPTIONS вы задавали в ~/.bashrc. Вроде бы предполагается, что для гуёвых программ source ~/.bashrc не должен происходить, по крайней мере так стал себя вести мой арч после какого-то апдейта. Окружение для иксовых прог задаётся в ~/.xprofile. Видимо на проблему вы наткнулись при работе с какими-то иксовыми прогами, а значит или лубунту у вас некорректно по-умолчанию сорсит для иксовых программ ~/.bashrc, или вы сами как-нибудь добились такого неканоничного поведения, например, прописыванием source ~/.bashrc в ~/.xprofile. В каноничном случае проблема опять-таки не возникла бы

strace -e trace=file sh -vx `which xdg-open` incoming/gridwars_lin.zip

Гм, действительно непонятно. Предлагаю рандомные танцы с бубном:
for shell in bash dash;do $shell `which xdg-open` incoming/gridwars_lin.zip; done
Попробовать заменить в xdg-open некорректно срабатывающее условие на -f или -e.

xdg-open обычный шелл скрипт, попробуйте протрейсить и посмотреть где спотыкается. Как-нибудь так:

sh -x `which xdg-open` incoming/gridwars_lin.zip

Блин, век живи - век учись. Вот никак не ожидал, увидев топик в RSS, что узнаю в нём что-нибудь для себя новое. И тут надо же. Я раньше использовал inotail -f, но tailf, конечно, удобнее.

Именно так. Использование аналогичного интерфейса в Windows 7 по-умолчанию свидетельствует, что это, в общем, удобно и не так уж сложно.


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

Множество кнопок в таскбаре в кедах тоже не проблема: даже дефолтный Task Manager апплет умеет группировать похожие кнопки в одну, если на панели становится тесно. А если его заменить на smooth-tasks, то отображение кнопок окон на панели станет совсем гибким и конфигурируемым.

Behold KDE power!

Всё исключительно средствами kwin и автоматически. Настройка:

1. Правой мышой по заголовку окна чата - Special window settings
2. Вкладка Window Extra,оставляем в Window Title только " - Skype™ Chat",правило меняем на Substring match
3. На вкладке Preferences ставим галку Autogroup by ID - Force - "Skype-chat" (вообще любая уникальная строка)
4. OK

Всё, открываемые чаты должны автоматически группироваться. Есть, впрочем, два недостатка: клик по кнопке закрытия окна, самой правой в заголовке, против ожидания закрывает только текущую вкладку-окно, а не все (у меня что-то криво в кедах настроено?); в taskbar'е по-прежнему каждому окне-вкладке соответствует своя кнопка.

Вот-вот! Хватит трубить котов!

$ man mc
/hotkey

А если глобально утихомирить винт?
hdparm -M 128 /dev/...Учтите, что от этого несколько возрастает время поиска.

Также есть мнение, что видимо дело в тормозах sqlite (dropbox там хранит свои данные) на ext4 разделах с опциями монтирования по-умолчанию. Попробуйте монтировать с barrier=0.

Уточняю себя.

1. Проще и сразу в человекочитаемых единицах измерения размер журнала можно узнать командойdumpe2fs /dev/sdb2 | grep -m1 'Journal size'
2. Вспомнил про свой LiveUSB со SLAX'ом, на котором изменения, сделанный в процессе работы, сохраняются в ext4 файлуху размером 192MiB. Проверил размер журнала на ней - оказалось 4MiB. Вообще man mke2fs говорит нам, что журнал может иметь размер от 1024 до 102400 блоков, что при стандартном размере блоков в 4k составляет 4-400MiB.

Так господа, вы тут так дружно в комментариях несли ересь про размер журнала, что я даже засомневался в собственных знаниях, а зря (там про ext3, но в ext4 по этому вопросу всё то же самое). Зато разобрался в новом для себя про размеры журналов. Насколько я понял, журнал в стандартной конфигурации - фактически обычный файл. Узнаем его inode:
inode=$(tune2fs -l /dev/sdb2|awk '/Journal inode/{print $3}')
А теперь узнаем размер:
debugfs -R "stat <$inode>" /dev/sdb2|grep -m1 Size:
Это будет в байтах. У меня размер журнала на всех ext4 разделах оказался 128MiB, т.е. не зависящим от размера ФС. Это и логично: журнал должен зависеть не от количества места, а от количества транзакций, информацию о которых он должен хранить, а это не так уж много - только те, которые находятся в обработке.

Сдаётся мне, что это нифига не журнал на 40 гектар, а зарезервированное для процессов рута место, чтобы они могли писать на диск даже когда для всех остальных место на нём типа кончилось. Посмотрите вывод tune2fs -l /dev/sdb2|grep -i reserved
При современных размерах дисков и 1го процента резерва должно хватать за глаза. Отрегулировать так
tune2fs -m 1 /dev/sdb2