Хокку от меня :)

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

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

в саду цветов ли, иль в саду вечных деревьев
все сбились с ног в поисках толстого самурая,
обнаружили только одного тощего

вышел самурай на порог своего жилища.
что-то беспокоит его пониже чёрного пояса.
сунул руку - неожиданная пропажа! потерял равновесие.

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

самурай на посту, а самурай на посту?!
совершите отдолжение мне, приличной гейше!
соедините пуговицей мой срамной орган с вашим головным убором!

из-за зарослей сакуры, из-за горы Фудзи, 
показал простолюдин орудие для рубки бамбука. 
не все догадались, к чему был привязан предмет. ​ ​

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

полюбила водителя железного коня.
посидела с ним на склоне Фудзи.
о боги! целый день мне не было покоя от зловоний!

дамп процесса с помощью GDB под Linux

Старая тема с VBto на иной лад старая тема была здесь: "взлом" результатов программы VBto дампингом памяти
так вот, дамп памяти можно произвести отладчиком, без вспомогательных программ из интернета

первым делом, узнаём номер процесса, к которому нужно прицепиться gdb:

ps -ef |grep nameOfYourProcess

левая колонка с номером покажет на номер процесса. затем вызываем отладчик, если номер нужного процесса 2575

gdb -q – 2575

после этого из консоли отладчика

(gdb) generate-core-file

"открепиться" от процесса

(gdb) detach

и выйти из дебаггера


(gdb) quit

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


strings core.2575 > core.txt

успехов!

нахождение потенциальных проблем "undefined symbol" в бинарниках

Ранее мной был написан скрипт для нахождения бинарников, к которым нет внешних библиотек. Но есть еще минимум одна неприятность, это устаревшие библиотеки. К примеру, бинарник компилировался с новейшей версией, а в дистрибутиве по недосмотру, или какой другой причине, была установлена старая версия. В этом случае программа может вывалиться с сообщением undefined symbol:

kdevelop: symbol lookup error: /usr/lib/kde4/kdevcmakemanager.so: undefined symbol: _ZN16CMakeParserUtils13includeScriptERK7QStringN8KDevelop22ReferencedTopDUContextEP16CMakeProjectDataS2_

На первый взгляд, не совсем понятно, что за символ такой, и к чему он принадлежит.
Но в Linux есть утилиты binutils, среди которых есть программка c++filt, которая, собственно, и может декодировать такие символьные строки.

c++filt _ZN16CMakeParserUtils13includeScriptERK7QStringN8KDevelop22ReferencedTopDUContextEP16CMakeProjectDataS2_

результат выполнения:
CMakeParserUtils::includeScript(QString const&, KDevelop::ReferencedTopDUContext, CMakeProjectData*, QString const&)

Ранее написанный скрипт здесь можно расширить для поиска таких бинарных файлов.

Применять для фильтрации "undefined symbol" можно командой

ldd -d -r nameOfBinFile

где  nameOfBinFile имя актуального бинарника, который можно использовать как переменную в цикле обработки скрипта.
затем преобразовывать из низкоуровневого представления в более простой для понимания текстовой вид.

ссылка на документ c++filt: link

Ремонт Samsung X20

Достался мне ноут Samsung X20. Попытался его я отремонтировать. Симптомы: при подключении адаптера питания светодиод начинает мигать - признак перегрузки. Ноутбук сам дотянул до полной разрядки батареи, т.к. зарядить уже ничего не мог.

Разбираю, подключаю сетевой адаптер. Сильно греется полевик SI4435, на первой фотке отмечен стрелкой.

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

На материнке первое, что сделал - проверил сопростивление на контактах для кондюка напряжения 18V, на рисунке обозначил зелёным цветом. 0.001 ом! теперь осталось найти причину. отпаивал поочерёдно находящиеся недалече SI4435 (обозначено синим), там есть еще один SI4431 около диода Шоттки, обозначил красным. После выпаянных SI4435 картина не менялась, но после SI4431 К.З. исчезло. Рядом с ним находился диод, который я тоже на всякий случай выпаял, чтобы проверить. Диод Шоттки оказался тоже пробитым.

После замены этих двух деталей ноутбук начал снова работать от сети и заряжать батарею.

На радостях установил Debian базированную систему, только дополнительно нужно было установить пакет для WLAN, скачать можно здесь

автоматическое улучшение качества плохого скана

вот еще одна тема, с которой мен пришлось столкнуться. нашел я одну книженцию на просторах интернета. качество её меня сильно не устроило.

при ближайшем рассмотрении можно увидеть много "шумов". читать можно но...

в программе GIMP я помотрел, можно ли что-нибудь улучшить, используя изменения кривых цвета. затем на ресурсе скриптов для ImageMagick я нашел подходящий скрипт curves.

Transformation Graph (curve with points drawn)

Подбирая две точки, нашел лучше всего подходящие параметры:
./curves -s 100,100 "25,25 75,95" test.jpg test_out.jpg

результат приведён ниже:

после этого, как и ранее, я применил скрипт для циклической обработки всех изображений книги:

#!/bin/bash
# loop_for_fotos.sh
#
SAVEIFS=$IFS
IFS=$(echo -en "\n\b")
#проверяем, установлен ли convert
convert > /dev/null
if [ $? -ne 0 ] ; then
    echo "Error: convert is needed, it's a part of ImageMagick" ;
fi;
DIR=$1;
# велосипед, убирающий "/" в конце
if [ -z $1 ]; then $DIR=`pwd`;
else
    TEMP=`pwd`;
    cd $DIR; TEMP2=`pwd`;
    cd $TEMP;
    DIR=$TEMP2;
    echo $TEMP2;
fi;
#наши старые файлы копируем в DIR.orig
echo $DIR
mkdir $DIR/orig;
cp *.jpg $DIR/orig/
ERR=0;
CPUS=1;
echo "Start in " $DIR
files=$(ls $DIR/*.jpg)
list=($files)
len=${#list[@]}
echo $len
CPUS=2;
echo "Start curve transformation"
for(( i=0; i<$len ; i=i+$CPUS))
do
    for(( j=0; j<$CPUS ; j++))
    do
    if [ ${list[i+j]} ]; then
#echo ${list[i+j]}
    ./curves -s 100,100 "25,25 75,95"  ${list[i+j]} ${list[i+j]}.new.jpg &
    fi
    done;
    for job in `jobs -p`
    do
    echo $job
    wait $job || let "FAIL+=1"
    done;
    if [ $? -eq 0 ]; then
    echo "curve transformation successfully ;) next step";
    else ERR=$[$ERR+1]; #считаем ошибки
    fi;
    for(( j=0; j<$CPUS ; j++))
    do
    if [ ${list[i+j]} ]; then
    mv  ${list[i+j]}.new.jpg ${list[i+j]}
    fi
    done;
done;

if [ $ERR -eq 0 ]; then
    echo "Job done!";
else echo "Job done with some errors.";
fi;
echo "You can find your old files in $DIR.orig"

IFS=$SAVEIFS
#end

попытки обрабатывать пробелы в именах файлов при помощи
SAVEIFS=$IFS
IFS=$(echo -en "\n\b")
...
IFS=$SAVEIFS

к успеху не привели, т.к. либо в скрипте curves, либо в самой конвертирующей программе выдаёт ошибку convert: unable to open image... более подробно не выяснял.

точки кривых всегда нужно выяснять экспериментальным путём, в зависимости от качества скана.

автор публикации - Карбофос.

уменьшение времени генерации locales на debian базированном дистрибутиве

Порой пакет locales актуализируется и при этом проводится генерация локалей для системы, видим:

Generating locales (this might take a while)...
de_DE.UTF-8... done
en_GB.UTF-8... done
en_US.UTF-8... done
ru_RU.UTF-8... done

в моём случае, чтобы не ждать очень долго генерации локалей, я подредактировал файл /etc/locale.gen, оставив в нем только те, которые мне могут пригодиться. при коротком списке актуализация проходит очень быстро. если список не изменять, то можно прождать несколько минут

дистрибутив: debian базированный

новая версия X.org server 1.11 закрыла КУЧУ УТЕЧЕК памяти. прогрессивное человечество вздохнуло с облегчением ;)

В последнее время наблюдал тихий ужас на моём компе

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1982 root 20 0 685m 587m 3360 S 31 29.2 6:27.83 Xorg

В общем, наблюдалось НЕЧТО, чему я не мог найти толком объяснения. В любом случае, я думал обо всем, чем угодно, но не об ошибках ТАКОГО УРОВНЯ.

Вчера проактуализировал свою систему, и, О, ЧУДО!!! :)

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1960 root 20 0 154m 32m 7116 S 6 1.6 0:27.05 Xorg

Железо на моём компе такое:

процессор AMD Athlon(tm) Dual Core Processor 4850e
видеокарта VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
плата MSI K9A2GM
система Linux 3.0-3-amd64

Вполне вероятно, что большинство ошибок утечки специфичны для 64bit систем...

Проявления: у меня на компе основная оболочка KDE 4, но запускал также и другие дистрибутивы с другими оболочками. Не было этой проблемы только на OpenSUSE 11.4, но там использовалась версия 1.9, а не 1.10.
При открытии объектов (всплывающие окна, объекты меню и пр.) было видно, что перед появлением информации в форме заготовка создавалась с содержимым-мусором, по всей видимости - содержимых других, уже занятых участков памяти. Выглядело примерно так: