В своё время обзавёлся большой карточкой для фотика, чтобы как можно дольше не удалять с него. Карточку подключал также через USB3-ридер. И вдруг... ридер перестал нормально работать с карточкой (вылезали ошибки). А потом я заметил, что и фотки с видео исчезли. Учитывая, что я бережно обращался с фотиком (за исключением использования этого ридера), не ожидал такого поворота.

В принципе, регулярно копировал файлы. Но не всё.

Попробовал photorec. Быстренько так! Но. Хм, помнится undelete под ДОСом для FATа просил указать только первую букву, т.к. она и затиралась при удалении для отметки этого процесса (ЕМНИП). photorec придумал какие-то свои числовые номера. Отчего?

Зато он сохранил время создания. Но только фоток, а видео mp4 - нет. Он что EXIF для этого использовал, а не атрибуты с ФАТа? Не помню, они там действительно потираются?

И самое интересное: сравнил оригинальные (прежде переписанные) файлы с восстановленными. Размер отличается. photorec сделал их на 16% компактней. При этом конверт в bmp подтверждает, что это одна и та же картинка. Так это теперь перед тем как переписывать файлы с фотика, их надо сначала удалить, а затем восстанавливать, т.к. даёт экономию места, или в чём дело?

Сейчас ищу быстрый и удобный способ наладить этот процесс:

• qemu/uml? (uml потенциально подходит, т.к. дело на данный момент не в драйвере);
• минималистичный дистрибутив, где было бы удобно и быстро «переустанавливать» ядро, не засоряя систему;
• git clone https://linux.org/... чтобы стянуть необходимый минимум (без истории, только linux-next);
• оформление, отсылка патча;
• что соблюдать, чтобы патч был принят/воспринят.

  Кто-нить реально проходил эти шаги до победного конца? Тогда поделитесь, пожалуйста, деталями.

Как обычно в дебиане: разархивировал gcc-4.7_4.7.2.orig.tar.gz, получил gcc-4.7-4.7.2.orig/gcc-4.7.2-dfsg.tar.xz. Хм, вот это необычно.

Разархивировал и его. Заархивировал как gcc-4.7_4.7.2.orig.tar.gz. Наложил diff.gz. И вперёд с dpkg-buildpackage.

Похоже, нужно как-то по-другому. Кто-то знает, что это за вид упаковки и как с ним правильно обращаться?

gag@debian:/home/gag/gcc/gcc-4.7-4.7.2.orig/gcc-4.7-4.7.2$ dpkg-buildpackage -uc -us
dpkg-buildpackage: source package gcc-4.7
dpkg-buildpackage: source version 4.7.2-6
dpkg-buildpackage: source changed by gag <g@g.org>
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build gcc-4.7-4.7.2
 fakeroot debian/rules clean
rm -rf stamps
rm -rf   d
/usr/bin/make -f debian/rules2 clean
make[1]: Entering directory `/home/gag/gcc/gcc-4.7-4.7.2.orig/gcc-4.7-4.7.2'
debian/rules2:10: debian/rules.parameters: No such file or directory
make[1]: *** No rule to make target `debian/rules.parameters'.  Stop.
make[1]: Leaving directory `/home/gag/gcc/gcc-4.7-4.7.2.orig/gcc-4.7-4.7.2'
make: [clean] Error 2 (ignored)
rm -rf /home/gag/gcc/gcc-4.7-4.7.2.orig/gcc-4.7-4.7.2/src* /home/gag/gcc/gcc-4.7-4.7.2.orig/gcc-4.7-4.7.2/build* debian/tmp* html
rm -f bootstrap-* first-move-stamp
rm -f autotools_files
rm -f debian/*.tmp
rm -f debian/soname-cache
find debian -name '.#*' | xargs -r rm -f
rm -f debian/patches/series*
dh_clean
 dpkg-source -b gcc-4.7-4.7.2
dpkg-source: info: using source format `1.0'
dpkg-source: info: building gcc-4.7 using existing gcc-4.7_4.7.2.orig.tar.gz
dpkg-source: info: building gcc-4.7 in gcc-4.7_4.7.2-6.diff.gz
dpkg-source: warning: executable mode 0755 of 'debian/dh_rmemptydirs' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'debian/dh_doclink' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'debian/locale-gen' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'debian/reduce-test-diff.awk' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'debian/logwatch.sh' will not be represented in diff
dpkg-source: info: building gcc-4.7 in gcc-4.7_4.7.2-6.dsc
 debian/rules build
echo -e "\nBuilt from Debian source package gcc-4.7-4.7.2-6" \
		> pxxx
echo -e "Integrated upstream packages in this version:\n" >> pxxx
for i in  ; do echo "  $i" >> pxxx; done
mv -f pxxx stamps/01-unpack-stamp
mv: cannot move `pxxx' to `stamps/01-unpack-stamp': No such file or directory
make: *** [stamps/01-unpack-stamp] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
gag@debian:/home/gag/gcc/gcc-4.7-4.7.2.orig/gcc-4.7-4.7.2$ 

Иду в 16-м огнелисе на

https://midnight-commander.org

https://www.midnight-commander.org

The certificate is not trusted because it is self-signed.
The certificate is only valid for midnight-commander.org

В ядро 3.7 добавят поддержку Altera SoC (который должен быть на Cyclone V FPGA). При этом доступность самих циклонов - 0. В тоже самое время Xilinx уже реально продаёт платку, но ядро у неё в своей отдельной ветке и они оправдываются, мол сложно/долго с апстримом договариваться. Это только у меня такая ассоциация Xilinx ~ nVidia, Altera ~ ATI/AMD?

Кто-то уже пробовал ZedBoard? Оказывается, её полноценный вариант даже в qemu уже есть (xilinx-zynq-a9) (странно, не могу найти анонса, когда именно добавили).

Обычно я пользуюсь gparted. Красиво и быстро.

Но сейчас понадобилось «записать» действия, чтобы не забыть. И не тут-то было. Оказалось, что parted - это не тоже самое, что gparted, только из консоли, а что-то совсем другое, из которого в версии 3.0 (30 мая 2011) удалили устаревшие функции по работе с файловыми системами.

Как же теперь из консоли делают resize/move, например, ntfs?

Обнаружил новость Russian-software-runs-x86-code-on-ARM.

Вроде LAMP есть и под armel, и под armhf. В крайнем случае и qemu, и bochs тоже под обе архитектуры есть.

Elbrus Technologies has developed emulation software that currently delivers 40 percent of native ARM performance. The company believes it could reach 80 percent native ARM performance or greater by the end of 2014.

Вот это не измерял.

А какого важного серверного ПО не хватает?

Кто-нить заглядывал на неофициальный баг-трекер AMD/ATI? Кажется ли мне это, или оно и есть так на самом деле, что им в AMD больше особо не интересуются?

Начиная с бага номер 414 и по 613 закрыты только 16 из... 200!

420, 429, 437, 438, 441, 442, 446, 455, 478, 491, 496, 504, 512, 552, 560, 588.

А остальные просто NEW.

Приглашаю RussianNeuroMancer.

По мотивам вопроса XVilka мне необходимо (желательно в octave) визуализировать динамически (т.е. можно покрутить) распределение плотности объекта: rho = f(x,y,z).

Т.е. вроде как и 4D, но в тоже время можно и в 3D, если rho будет в виде интенсивности цвета/прозрачности. Т.е. сам объект будет смотреться дискретным. Такие себе жирные полупрозрачные шарики в пространстве. Чем больше rho, тем жирнее/менее прозрачно. x,y,z - целые числа, в частности индексы 3D-матрицы, значения которой - rho.

P.S. Что-то сопровождающий пакета mathgl в дебиане с января больше не обновляет. Разработчик пакета, кстати, вправе его настоятельно попросить так уж откровенно не игнорировать upstream?

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

Так вот казалось бы, что может быть проще функции itoa()? Т.е. если её реализовать по-другому - неужели это такое изобретение, которое подпадает под GPL? Т.е. на целую прогу/либу GPL - да, но вот на пару строчек!

А потом найдётся кто-то, кто скажет, что вот моя kij-реализация перемножения двух матриц быстрее других (ijk, kji,..), и я ею делюсь со всеми, НО под GPL. Да, 3 цикла - и всё, кто использовал, тот должен теперь всю свою либу/прогу GPL-ной сделать, и все те, кто эту либу используют, и все,....

GPL - это по-своему хорошо. До тех пор, пока она не доходит до такого же абсурда, как противные нам патенты оракла на несколько строчек в джаве.

Сейчас мучаясь с одной ошибкой в opencl/gl interop заметил файлик в проприетарном амдшном драйвере common/lib/modules/fglrx/build_mod/kcl_iommu.cpp.

Я что-то пропустил, и карточки уже пробрасываются в qemu-kvm?

Сам скриптик заработал в octave без проблем, но пришлось выкинуть aviread(), что очень сильно снизило удобство работы. Итак:

                             octave    C/opencv    C/fftw
загрузить/сохранить видео       -          +         n/a
захват видео с web-камеры       -          +         n/a
1D/2D/3D БПФ                  +/+/+      +/+/(+)    +/+/+
переносимость                   +          +          +
размер                          -          -          +
прототип/производительность    +/-        -/+        -/+

Вопрос: может я что-то важное пропустил (пакет octave-video выкинули из дебиана)? Использовал кто-нибудь какую маленькую переносимую библиотеку для получения видео с web-камер? При отказе от opencv придётся лезть в libav или есть лёгкие альтернативы?

Год назад добавили SB900: http://blogs.coreboot.org/blog/2011/06/27/amd-contributes-a-series-family-12-...

Казалось бы производитель - молодец, постарался очень быстро ни то что предоставить спеки, а даже патчи. А на страничке coreboot'а сейчас, год спустя, по-прежнему нет упоминания. Я чего-то не заметил или есть ещё места, где они публикуют актуальную инфу? Или AMD что-то важное «забыла» добавить?

Занимаюсь по-прежнему встраиванием интепретаторов скриптовых языков в C. Под Debian Wheezy (testing) установил пакеты python2.7-dbg, perl-debug, libruby1.9.1-dbg, liblua5.1-0-dbg, liblua5.2-0-dbg.

C питоном и перлом - всё ОК. А вот с руби и луа - непонятно, т.е. никакого эффекта. И такое содержимое пакетов -dbg вижу впервые:

/usr/lib/debug/.build-id/20/f24873e3a0539be454e1ef9201acf86c60b25a.debug
...

Нужно что-то ещё указать при вызове gcc?

В документации к встраиванию интерпретатора перла в свою прогу, скажем, на C сообщается, что необходимо манипулировать C runtime environment. Это приводит к тому, что инициализировать/деинициализировать можно только один раз. При попытке сделать это два раза - облом. Пробовал выгружать эту процедуру в разделяемую библиотеку и дёргать её dlopen/dlclose - не помогает. Перлу удаётся как-то сохранить инфу о том, что его уже один раз старт-стопнули.

Значит, можно как-то из плагина, скажем, узнать сколько раз он был загружен, не изменяя(!) test_dl.c? Вот минимальный образец. Вопрос: как?

test_dl.c

#include <stdio.h>
#include <dlfcn.h>

typedef void (*Func)(void);

const char *filename = "libdl_func.so.1.0.0";

int main(int argc, char *argv[], char **env)
{
        void *plugin_handle;
        int i;

        for (i = 0; i < 2; i++) {
                plugin_handle = dlopen(filename, RTLD_LAZY | RTLD_GLOBAL);
                if (!plugin_handle) {
                        printf("failed to load library!\n");
                        return 1;
                }
                Func func = (Func) dlsym(plugin_handle, "func");
                func();
                dlclose(plugin_handle);
        }

        return 0;
}

dl_func.c:

#include <stdio.h>

void func()
{
        printf("called\n");
        //printf("load count=%d\n", ???);
}

makefile

CC=gcc
CFLAGS=-Wall -g

all: libdl_func.so.1.0.0 test_dl

libdl_func.so.1.0.0: dl_func.o
        $(CC) -o $@ $^ -shared -Wl,-soname,libdl_func.so.1
#       ln -s libdl_func.so.1.0.0 libdl_func.so.1

dl_func.o: dl_func.c
        $(CC) $(CFLAGS) -fPIC -c dl_func.c

test_dl: test_dl.o
        $(CC) -o $@ $^ -ldl

test_dl.o: test_dl.c
        $(CC) $(CFLAGS) -c $<

clean:
        rm -f libdl_func.so.1.0.0 libdl_func.so.1 dl_func.o test_dl.o test_dl

Проверяю чистоту встраивания ruby в C. Выходит: finalize() не производит полную очистку. Или чего-то не хватает при инициализации, или есть ещё что-то к finalize(), или bug?

Минимальный пример:

// test_embed_ruby.c
// gcc -Wall -g -o test_embed_ruby test_embed_ruby.c -I/usr/include/ruby-1.9.1 -I/usr/include/ruby-1.9.1/x86_64-linux -lruby-1.9.1

#include <stdio.h>
#include <ruby.h>

void call_ruby(void)
{
        printf("init...\n");
        ruby_init();

        printf("init_loadpath...\n");
        ruby_init_loadpath();

        printf("finalize...\n");
        ruby_finalize();
}

int main(int argc, char *argv[])
{
        printf("1\n");
        call_ruby();
        printf("2\n");
        call_ruby();

        return 0;
}

Есть пример использования pdsyev. После указанной правки всё работает.

Но при изменении конфигурации сетки:

было: матрица 4x4, процессы: 2x2, т.е. каждый процесс получает 2x2-кусок матрицы (prow=2; pcol=2; brow=2; bcol=2;).

пробую: матрица 4x4, процессы: 1x4, т.е. каждый процесс получает 4x1-кусок матрицы (prow=1; pcol=4; brow=4; bcol=1;).

pdsyev кричит, что невалиден параметр 709 (или около того).

Похоже, нужно ещё где-то крутить, но не вижу где.

P.S. Кстати, а в удобных пакетах типа octave, scilab,... имеется поддержка распределённых вычислений? А то от libscalapack-mpi1 у меня в дебиане что-то почти ничего не зависит. Да и гугл недавно открыл код алгортима для их карт, так он использует не lapack, а eugen.

Вчера подняли тему скорости сборки после внесения изменений в проект. И вопрос, что надо просто правильно писать, чтобы после незначительных изменений быстро пересобиралось.

А как быть с изменением private элементов класса, который является базовым для нескольких других классов? Ведь такое изменение придётся сделать в заголовочном файле. И несмотря на то, что оно по определению не может повлиять на другие классы, make этого не знает и оценит только время модификации .h. Или кто-то кроме make'а уже умеет заглядывать в .h?

В https://www.virtualbox.org/wiki/Changelog к версии 4.1.12 есть сообщение

VMM: proper Math Fault handling with certain legacy guests (bug #9042)

Заканчивается на ноте «не исправим». Хм, но кто-то якобы исправил.

Смотрим список изменений, ищем VMM. Вроде ничего релевантного нет.

Вроде, как virtualbox - не любительский проект. Но организация учёта ошибок/кода как-то непрофессионально выглядит. Я ожидал перекрёстные ссылки (баг->коммит с фиксом, коммит->какой баг фиксит, если имело место быть). Там есть ещё какой web svn, который я не заметил, или вот так вот у них заведено?

Становится всё сложней не обновлять gnome'овские пакеты в debian wheezy на моих стационарных ПК. Так что начинаю активно пробовать mate/cinnamon на ноуте. Возникли проблемы с переключателем раскладок (когда-то из-за него я перешёл с КДЕ на гнома. Ну, ладно, ещё из-за того, что гном дефолтный в дебиане). С флажками разобрался. Но не могу найти опции переключения перебора раскладок: вперёд-назад и по-кругу.

Раскладка у меня: us-ru-ua-de. По умолчанию: us, при нажатии левого alt-shift: ->ru->ua->de->us, правого alt-shift: ->de->ua->ru->us.

Но в новых гномах оно теперь только в одну сторону работает! Оно-то работает, но я так вообще не могу.

P.S. И в догонку: не нашёл графического gconf-editor для mate. dconf-editor показывает только для gnome3 (и, значит, cinnamon?).