dump -0f - /dev/mind

У меня в ЖЖ было куча ссылок между постами, и я хотел в DW поправить их так, чтобы они вели на соответствующие посты в DW.

Оказалось, что все велосипеды уже придуманы до нас :) Вот тут человек наколхозил скрипт, который пробегает по архиву, сделанному ljdump, собирает соответствия между URL-ами в ЖЖ и DW, правит посты и обновляет их в DW.

Из коробки скрипт у меня не заработал, пришлось его чуть поправить, чтобы он умел работать с ЖЖ-никами, в которых есть подчеркивания (как это было у меня). Результат на github-е (https://github.com/adept/ljdump/blob/master/fix_links.py), запускать из директории с результатами ljdump.

Оно будет показывать diff для всех поправленных постов и после подтверждения обновлять их. Можно выбрать альтернативную программу для сравнения через переменную окружения DIFF.

Я запускал так: DIFF=patdiff ~/path/to/fix_links.py

Вроде бы как все переехало нормально, ссылки поправлены, ничего не поломалось.

UPD: Заодно, вписав в скрипт пару строк вида url['вот это']='заменить на это', пофиксил все картинки, которые поломались после того, как dropbox закрыл public фолдеры. Красота!

Обращаюсь за помощью к коллективному разуму.

Есть у меня NAS с RAID-ом. На нем - ~400 Gb Ценных Данных. Хочется их на куда-то сбекапить off-site, на случай непредвиденных обстоятельств - если вдруг RAID накроется целиком и сразу весь.

Хочется, чтобы:
1)Лить бэкап можно было прямо с NAS-а (а там - linux и ARM), то если либо по rsync, либо по ftp/ssl или sft, либо еще что-то подобное, и уж точно не какой-то GUI-клиент.
2)Все, что я лью туда, должно быть зашифровано (допустим, каким-то симметричным алогоритмом с большим ключом).
3)Версионированиие и прочие модные штуки (доступ с мобилки, шаринг файлов, фото-альбомы(!)) - не нужны.
4)Супер-пупер надежность с 29-ю девятками после запятой - тоже не нужна. Мне нужна разумная страховка на случай, если с моей стороны случится что-то маловероятное, а не основное средство для бэкапа. Для меня будет достаточно, если они скажут "извини, тут с вот этим файлом беда вышла - надо перезалить".
5)Инкрементальные бэкапы - обязательны

Вроде ж не много хочу, да? ( И вот что выяснилось ... )

Некоторое время тому назад я писал (http://dastapov.dreamwidth.org/78794.html) о скрипте, с помощью которого я извлекаю данные о фильмах с сайта imdb.com. После нескольких недель эксплуатации скрипт оброс дополнительными возможностями, главная из которых - "декодирование" оценки фильма с помощью IMDB Movie Decoder Ring.

Что это за "декодирование" и зачем оно нужно? А для того, чтобы ответить на вопрос: "фильм с оценкой 6.1 - это фильм плохой, хороший или так себе?". Если бы оценки посетителей были бы распределены равномерно в интервале от 1 до 10, то можно было бы утверждать, что фильм с оценкой 6.1 - скорее хороший, чем средний. Однако фильмов с оценкой 1 и 2 на imdb.com почти нет, а фильмов с оценкой в интервале [5;7] - очень много. Как же можно содержательно интерпретировать оценку?

Например, так: можно заменить оценку X на процентное отношение фильмов, имеющих оценку <=X, к общему количеству фильмов. Если более 50% фильмов в базе imdb.com имеют оценку <=X, то можно считать, что фильм - скорее хороший. Более того, подобные процентные отношения можно рассчитать отдельно для всех жанров, к которым относится фильм, и тогда можно будет ответить на вопрос, как выбранная нами мелодрама (жанры Comedy, Drama) соотносится с другими комедиями и драмами.

Чтобы не выполнять каждый раз обработку всей базы imdb, Tom Moertel свел подобные расчеты в удобную компактную таблицу, которую он назвал IMDB Movie Decoder Ring. Табличка эта предназначена для использования вручную, но я, как человек ленивый, тоже не захотел связываться с обработкой сырых данных с imdb.com, и запихнул эту табличку в свой скрипт. Теперь в таблице результатов добавились две колонки: процент всех фильмов, оцененных ниже, чем этот, и (в отдельной колонке) подобные проценты по всем жанрам фильма, через запятую.

В результате можно выяснить, что, например, фильм "Broken English (2007)", имеющий оценку 6.3 -- едва-едва попадает в категорию "скорее хорошие". Он "лучше" всего 51% фильмов в базе imdb. Кроме того, если посмотреть на его положение в каждом из жанров -- Comedy, Drama, Romance -- то окажется, что он лучше 55% комедий, но - всего лишь 42% драм и 46% романтических фильмов. Получается, что для комедии оценка 6.3 - это "хорошо", а для драмы - всего лишь "удовлетворительно.

Полный текст скрипта - под катом.( Read more... )

Понадобилось мне выкачать все полноразмерные фотографии из некоего альбома, опубликованого в Picasaweb. Около 80 фоток. Кликать на каждое preview и делать "save image as ..." - долго и моторошно. Из подручных средств сложилось вот такое решение:( фиговину прикладываем к хреновине, а потом со всей дури @#$!% сверху молотком )
Наверняка я изобрел велосипед. Ну и фиг с ним :)
Рецепт пусть остается мне для истории, а вам, возможно, пригодится ссылочка на Xtract.

Во френдленте пробежала череда постов о том, что оказывается можно листать странички в браузере при помощи Space и Shift-Space, обычно - с комментарием типа "Обана! 5/10/15 лет за компом, и не знал!".

Ну, для меня, пользующегося less с конца 90-х годов прошлого века(как звучит!) эта "новость" оказалась вовсе и не новость. Зато я вспомнил другую вещь, с которой я протормозил лет эдак на 5-10. Спешу поделиться :)

Недели три тому назад я с подачи helge9210 добавил в опции монтирования файловых систем /var, /usr и /home опцию "noatime". Скорость выполнения некоторых дискожручих операций (типа "apt-cache search", индексирование и поиск почты, find, ...) визуально увеличилась в разы, а иногда - на порядок.

Спрашивается в задаче - почему я не сделал это раньше? Например, параллельно с появлением DMA transfers в мохнатом 199x году :)

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

Итак, проблема:
Дано: компьютер с linux-ом, libdvdread с включенной поддержкой DeCSS, мешок видеопроигрывателей (mplayer, xine, totem, vlc, ogle), DVD с фильмом "Пираты Карибского Моря".

Проблема: при попытке проиграть DVD получаем либо "Sector read error", либо сообщения о том, что "libdvdread: Error cracking CSS key". Правда, какие-то ключи все-таки ломаются, он сильно это не помогает - фильм все равно не показывается ни одним из проигрывателей (вместо видео - мусор, вместо аудио - шум). На соседнем компьютере с теми же версиями софта - все проигрывается.

Решение:

Оказывается, libdvdread не умеет ломать CSS-ключи на некоторых новых DVD-приводах, если у этих самых приводов не выставлен "DVD region". Я про ту самую настройку, которая в теории должна ограничивать возможность просмотра DVD, произведеных в "далеких странах" и которую можно поменять всего два-три раза, после чего привод отказывается работать (или как-то так). На практике все на эту настройку забивают, чтобы пользователь не выкинул шибко умное железо на мусорник.

Да, так вот. Если у моего привода вообще не устанавливать этот "регион", то ключи ломаться не будут. А если поставить програмку "regionset" (apt-get install regionset) и с ее помощью установить любое значение "DVD region", то все начинает работать.

Правда, не сразу - сначала надо удалить из ~/.dvdcss те ключи, которые libdvdread якобы сломал до установки "DVD region". После этого ключи будут вычислены по-новой и все заработает.

Have fun.