Сегодня Нике исполнилось бы пять лет.
Плюс-минус несколько дней, потому что точную дату ее рождения нам сказать не смогли…
Сегодня Нике исполнилось бы пять лет.
Плюс-минус несколько дней, потому что точную дату ее рождения нам сказать не смогли…
![]() |
Вот и закончилась наша небольшая история. Остались смешанные чувства — и радость и печаль, жизнь возвращается в прежнее русло. Но конец нашей истории — это начало четырёх других историй, радостных, интересных и наполненных любовью. Иначе и быть не может! ;) |
Недавно я нашёл интересный файл в исходниках пакета iso-codes. Вернее, даже несколько файлов. В файле iso_639.xml (просмотреть) есть двух- и трёхбуквенные коды языков и их полное наименование. А в файле iso_3166.xml (просмотреть) — двух- и трёхбуквенные коды стран и территорий и их полное наименование. Вот кусочек одного файла:
<iso_639_entry iso_639_2B_code="afr" iso_639_2T_code="afr" iso_639_1_code="af" name="Afrikaans" /> <iso_639_entry iso_639_2B_code="ain" iso_639_2T_code="ain" name="Ainu" />
Я пишу в основном на shell для busybox. И я не работал с форматом XML. Гораздо проще было бы обрабатывать простой текстовый файл, в котором то же самое было бы записано вот так:
|af|afr|afr|Afrikaans| | |ain|ain|Ainu|
Тогда при помощи grep можно было бы выбрать из файла строку с нужным языком, дальше при помощи cut в этой строке выделить наименование языка. А уже потом, при необходимости, можно это наименование перевести на другой язык, используя переводы из этого же пакета iso-codes. Вот так:
LANGUAGE_CODE="af" LANGUAGE=$(grep -F "|$LANGUAGE_CODE|" /path/to/iso_639.tab | cut -d'|' -f5) echo "$LANGUAGE_CODE : $LANGUAGE : $(gettext -d iso_639 $LANGUAGE)"
Дело осталось за малым — нужно сделать эти tab-файлы. Можно, конечно, использовать текстовый редактор и при помощи поиска с заменой, а потом еще и при помощи напильника выполнить задачу. Но это отнимает много времени, и всё придётся повторять при выходе новой версии пакета iso-codes. Нужно это как-то автоматизировать.
Первым делом в голову почему-то пришло название — xmllint. Я повозился с ним, погуглил, но так и не смог добиться цели. Максимум пользы от xmllint было в том, что если ему на вход подать xml-файл, то он его «облагородит»:
xmllint /path/to/iso_639.xml
<iso_639_entry iso_639_2B_code="afr" iso_639_2T_code="afr" iso_639_1_code="af" name="Afrikaans" /> <iso_639_entry iso_639_2B_code="ain" iso_639_2T_code="ain" name="Ainu" />
Так, уже лучше. Это уже почти то, что нужно — одно определение теперь занимает одну строку. Что ж, вот несложный скрипт в качестве «напильника»:
#!/bin/sh
TEMP=$(mktemp)
xmllint $1 | grep '<iso_639_entry' > $TEMP
while read line; do
iso_639_2B_code="$(echo $line | sed 's|.* iso_639_2B_code=\"\([^"]*\)\".*|\1|')"
iso_639_2T_code="$(echo $line | sed 's|.* iso_639_2T_code=\"\([^"]*\)\".*|\1|')"
iso_639_1_code="$(echo $line | grep iso_639_1_code | sed 's|.* iso_639_1_code=\"\([^"]*\)\".*|\1|')"
name="$(echo $line | sed 's|.* name=\"\([^"]*\)\".*|\1|')"
common_name="$(echo $line | grep common_name | sed 's|.* common_name=\"\([^"]*\)\".*|\1|')"
[ "x$iso_639_1_code" == "x" ] && iso_639_1_code=" "
echo "|$iso_639_1_code|$iso_639_2B_code|$iso_639_2T_code|$name|$common_name"
done < $TEMP
Скрипт работает, выполняет своё дело. Но какой же он медленный!
real 0m 49.83s user 0m 44.09s sys 0m 12.40s
Да к тому же и процессор нагружает около 100%.
Писать на shell легко, но программы получаются далеко не эффективными и это особенно заметно на таких вот циклах. Я буду продолжать писать на shell, но этот кусочек я хотел бы переделать.
Я погуглил ещё на тему преобразования и трансформации XML и в конце-концов вышел на хороший пример, который пришлось только немного переделать под мой файл.
На сцену выходит утилита xsltproc. Она умеет преобразовывать файл XML в соответствии с правилами, заложенными в указанном файле XSL. Некоторая аналогия с информацией, находящейся в HTML и правилами в CSS. Да, как-то много лет назад я возился с XML и XSL но, конечно же, подробности забылись и тогда я не сделал каких-то особенных успехов. Получится ли сейчас? Да, к счастью, задача оказалась простой. Вот файл iso_639.xsl:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" />
<xsl:template match="/">
<xsl:for-each select="//iso_639_entries/*">
<xsl:text>|</xsl:text>
<xsl:if test="not(@iso_639_1_code)">
<xsl:text> </xsl:text>
</xsl:if>
<xsl:value-of select="@iso_639_1_code" />
<xsl:text>|</xsl:text>
<xsl:value-of select="@iso_639_2B_code" />
<xsl:text>|</xsl:text>
<xsl:value-of select="@iso_639_2T_code" />
<xsl:text>|</xsl:text>
<xsl:value-of select="@name" />
<xsl:text>|</xsl:text>
<xsl:value-of select="@common_name" />
<xsl:text> </xsl:text>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
Здесь для каждой записи выводятся через разделители «|» параметры iso_639_1_code, iso_639_2B_code, iso_639_2T_code, name, common_name. Причём iso_639_1_code и common_name могут отсутствовать. Я «для красоты» сделал так, если отсутствует iso_639_1_code (двухбуквенный код), то выводить два пробела. Так табличка выглядит ровной при просмотре глазами. Запускается преобразование командой:
xsltproc iso_639.xsl iso_639.xml > iso_639.tab
Вот его время работы:
real 0m 0.03s user 0m 0.03s sys 0m 0.00s
Чёрт! Впечатляет!
Почти так же был написан и файл iso_3166.xsl. Отличие только в том, что теперь файл XML состоит из двух частей. В первой части — действующие коды, а во второй — исторические, как например, СССР. Для исторических кодов применяется немного другой формат, например указано, когда этот СССР развалился и код перестал действовать.
Вот, собственно, и сам файл iso_3166.xsl:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="text" /> <xsl:template match="/"> <xsl:for-each select="//iso_3166_entries/iso_3166_entry"> <xsl:text>|</xsl:text> <xsl:value-of select="@alpha_2_code" /> <xsl:text>|</xsl:text> <xsl:value-of select="@alpha_3_code" /> <xsl:text>|</xsl:text> <xsl:value-of select="@numeric_code" /> <xsl:text>|</xsl:text> <xsl:value-of select="@name" /> <xsl:text>|</xsl:text> <xsl:value-of select="@official_name" /> <xsl:text>|</xsl:text> <xsl:value-of select="@common_name" /> <xsl:text>|</xsl:text> <xsl:text> </xsl:text> </xsl:for-each> <xsl:text> </xsl:text> <xsl:for-each select="//iso_3166_entries/iso_3166_3_entry"> <xsl:text>|</xsl:text> <xsl:value-of select="@alpha_4_code" /> <xsl:text>|</xsl:text> <xsl:value-of select="@alpha_3_code" /> <xsl:text>|</xsl:text> <xsl:value-of select="@numeric_code" /> <xsl:text>|</xsl:text> <xsl:value-of select="@date_withdrawn" /> <xsl:text>|</xsl:text> <xsl:value-of select="@names" /> <xsl:text>|</xsl:text> <xsl:value-of select="@comment" /> <xsl:text>|</xsl:text> <xsl:text> </xsl:text> </xsl:for-each> </xsl:template> </xsl:stylesheet>
Ну вот и всё. Если мне когда-нибудь понадобится преобразовать XML в CSV, я буду знать что делать.
Я хочу провести небольшую, но содержательную экскурсию на тему «От идеи до готового пакета».
Всё начинается с идеи, с желания видеть определенную программу в SliTaz.
Сделаем шаг в сторону. Существует множество дистрибутивов, основанных на пакетной базе Debian. Эти дистрибутивы просто берут у них готовые пакеты, возможно, перепаковывают в свой формат, но это не наш путь. В SliTaz имеется лишь небольшое количество «позаимствованных» пакетов. Для получения этих пакетов разработаны скрипты, названия которых начинаются на «get-»: вот их полный список. Во всех остальных случаях пакеты для SliTaz компилируются из исходного кода и упаковываются в самом SliTaz. Это позволяет компилировать программы выбранным компилятором, с выбранными опциями (иногда можно запретить или разрешить какую-то особенность программы, что в конечном итоге повлияет на полезность и размер программы), с точно совпадающим к нашим условиям набором системных библиотек (программа, скомпилированная в более новой среде в «чужом» дистрибутиве, будет требовать новые библиотеки).
Возвращаемся из этого закоулка на наш путь. Программы (пакеты) компилируются из исходников. Это можно сделать вручную, но тут больше рутины, чем творчества, а также присутствует элемент случайности и непредсказуемости. Количество готовых пакетов в SliTaz медленно, но верно приближается к 4 тысячам (3899). Был разработан инструмент, убирающий рутину из процесса создания пакетов. Он настолько удобный, что я уже давно ничего не компилирую вручную. Текущая инкарнация этого инструмента называется Cookutils. Это «сборочный бот». Он получает на входе «рецепт» с четкими указаниями и выдает на выходе готовый пакет.
Вот как выглядит рецепт для GPartEd: pkgs.slitaz.org/search.sh?receipt=gparted&version=cooking
Формат рецепта совместим с форматом shell-скриптов. Здесь мы видим комментарии, начинающиеся со знака «#», определение всех необходимых переменных и функций. В функции бота входят: загрузить архив с исходниками, распаковать его, установить все пакеты, необходимые для компиляции и сборки данного пакета, запустить { конфигурирование исходников, их сборку и установку }(по правилам, предусмотренным разработчиками пакета) [с учетом параметров, которые нам необходимы, например, устанавливать программу не в /usr/local/bin, а в /usr/bin], собрать из скомпилированных файлов кусочек файловой системы и создать из него пакет, после этого «подчистить за собой», убрав пакеты, которые были установлены перед компиляцией этой программы, вернув сборочную систему в исходное состояние.
Рутина убрана, осталось творчество ;)
Обычно, рецепты написаны таким образом, что достаточно изменить в нём номер версии в переменной VERSION для того, чтобы можно было собрать пакет с новой версией (если разработчики данной программы не привнесли туда чего-то кардинально нового, т.е. в случае минорных изменений).
Теперь нужно рассказать, как управлять таким огромным количеством рецептов, ну, и самим ботом.
Для хранения рецептов применяется система контроля версий Mercurial (Hg, ртуть). Это очень удобно, все изменения записываются, их можно окинуть взглядом и проанализировать. Вот так, например, выглядит «биография», история рецепта пакета GPartEd (начало внизу): hg.slitaz.org/wok/log/tip/gparted/receipt
Оказывается, ему уже 5 лет! И он вырос с версии 0.3.3 до 0.14.1 за это время.
Кстати, система Mercurial консольная, она установлена на одном из серверов проекта SliTaz, а то, что мы видели сейчас — это ее веб-интерфейс. Это очень удобно, потому-что веб-браузеры сейчас есть сейчас не то, что в мобилках, но даже в некоторых холодильниках! ;)
Mercurial позволяет разработчикам совместно выполнять свою работу. Достаточно установить себе Mercurial и сделать локальную копию хранилища рецептов (называется wok), а потом периодически обновлять локальную копию, чтобы получить изменения сделанные другими, а также вносить свои изменения в копию, находящуюся на сервере, чтобы наши изменения могли увидеть другие.
Нужно отметить, что имеется три версии wok: набор рецептов для текущей стабильной версии SliTaz (wok-stable), для разрабатываемой следующей версии (wok) и экспериментальный (wok-undigest, где допустимы любые эксперименты с «отклонением от генеральной линии партии»).
Остался один, вполне логичный шаг от wok к сборочному боту. Посредством cron бот активируется и проверяет изменения во всех wok (для wok и wok-stable это происходит каждые 2 часа, а для wok-undigest — реже, каждые 4 часа). При отсутствии изменений бот опять «впадает в спячку», а при наличии — собирает новые пакеты.
Сборочный бот имеет свой веб-интерфейс: cook.slitaz.org.
Здесь можно увидеть его текущее состояние, какие пакеты собрались, а какие — нет, просмотреть журналы компиляции. После сборки пакетов, раз в сутки они отправляются с сервера бота на сервер Mirror, откуда они становятся доступными всем пользователям SliTaz. С сервера Mirror происходит «зеркалирование» и на другие сервера.
Это была история о том, какой путь проходит от идеи до пакета в вашем пакетном менеджере. Но «за кадром» всё же осталось много интересного.
Откуда берётся номенклатура пакетов? Ходим-бродим по интернету, ищем, чего бы еще собрать. Прислушиваемся к пожеланиям пользователей. Не всё удается собрать. Иногда не хватает нужных пакетов-зависимостей, иногда — опыта.
Тратится определенное время на написание рецепта и его отладку. Работа проводится с локальным, установленным на своей машине, сборочным ботом. После того, как пакет собрался и программа запустилась и работает так, как от нее ожидают, рецепт забрасывается в wok.
Почему мы не можем иметь в текущей стабильной версии SliTaz новые версии пакетов? Ведь в разрабатываемой версии давно уже имеются работающие новые версии и новые пакеты. Ключевое слово здесь: «стабильность». Инфраструктура пакетов имеет сложную взаимосвязь. Никогда не слышали присказку: «не было печали, апдейтов накачали»? У нас пока еще нет инструмента, позволяющего определенно сказать, будет ли всё работать, или (уже бывшая) система «рухнет» или «накроется медным тазом». Разве что, кто-нибудь напишет этот инструмент. Нет людей, готовых тестировать новые пакеты для текущей версии в связке с другими пакетами. Перед выпуском новой стабильной версии произойдут обычные и закономерные действия. Сначала все пакеты программ и их зависимости (и зависимости зависимостей), в общем, все будут пару раз (для верности) пересобраны сборочным ботом. При наличии ошибок, они будут устраняться. При отсутствии ошибок будет выпущен RC1 (Release Candidate No. 1) — кандидат на выпуск следующей версии SliTaz. После тестирования RC1 на различном оборудовании и в различных условиях всеми желающими пользователями SliTaz, будут исправляться ошибки и недочеты в работе RC1. Будет выпущен RC2, и так далее, пока команде разработчиков система не покажется достаточно пригодной и стабильной. И тогда, какой-нибудь RC3 и будет назван новой стабильной версией.
Как проверяются зависимости? Эта работа возлагается на конфигуратор, находящийся в пакете с исходниками. Он ищет всё необходимое для того, чтобы пакет мог быть собран. Если чего-то не хватает, то он «громко падает» и до компиляции дело не доходит.
Принимаются вопросы, пожелания, уточнения…
Статья была написана как ответ на тему форума SliTaz Как обновляются пакеты?
Прочитав оригинальную заметку Кристофа Линкольна, основателя проекта с открытым исходным кодом — дистрибутива SliTaz, мне сильно захотелось, чтобы и вы её прочитали. Здесь я привожу свой перевод этой заметки на русский язык.
Вчера вечером в дверь позвонил почтальон и, не выходя из дому, я стал счастливым обладателем приза.
Вчера открыл для себя изысканное развлечение — запуск Linux-системы в обычном веб-браузере. На странице после загрузки системы получаем знакомую консоль, в которой можно писать привычные команды и получать ответы системы. Причём, это никакая не бутафория — в браузере реально работает ядро linux в минимальном busybox-окружении. Дождались! :) Как же это работает?
Завершился конкурс на лучшую русскоязычную статью Ubuntu 2011. Итоги конкурса были подведены 17 октября 2011 года. Результаты можно увидеть на странице konkurs.ubuntu.ru. Просмотрев список победителей, я не поверил своим глазам!
Вообще же, название этой короткой заметки довольно произвольно. Можно было бы назвать «NTFS и Linux Mint 11», или «NTFS и NTFS-3g» или как-нибудь в этом роде. Но, то, что я увидел, поразило меня!
В прошлый раз мы научились загружать страницы, анализировать их, посылать запросы и извлекать со страниц необходимые данные. Имея такой опыт, можно автоматизировать многие процессы. К этому мы еще не раз обязательно вернемся.
С 1.10.2011 г в Системе самообслуживания PeopleNet снова стала доступна детализация трафика. Поэтому сегодня мы напишем новый скрипт для проверки остатков, лишенный недостатков предыдущего…
Просматривая статьи, присланные на конкурс статей Ubuntu 2011, нахожу немало интересного. ☺ Кое-чем хочется поделиться с читателями. Не просто пересказать написанную статью, а пойти дальше. Как вот в этом случае…
В данной статье рассматривается процесс создания скрипта для проверки баланса украинского мобильного оператора PeopleNet, который обычно используется для мобильного доступа к 3G интернету. Целью статьи является популяризация написания скриптов для облегчения ежедневных задач.
Таким вот странным словом (palimpsest) называется главный бинарник из пакета gnome-disk-utility.
После установки появляется в меню Администрирование под названием Дисковая утилита.
Утилитка действительно достойная. В ней можно форматировать разделы и разбивать диски на эти разделы. Но, больше всего мне понравился другой функционал — во-первых, утилита позволяет определять «здоровье» жестких дисков при помощи опроса параметров SMART и самотестирования диска, и, во-вторых, утилита умеет определять скоростные характеристики дисков при помощи тестирования (чтение). Я сравнил несколько своих флешек, и флешек друзей, которые были в пределах моей досягаемости и поделюсь здесь с вами результатами.
У меня имеются два USB-модема.
На первый взгляд у них общее то, что при втыкании модема появляется устройство /dev/ttyACM0. В принципе, особых проблем с обоими модемами нету. Но, вот, встроенный в панель Апплет NetworkManager просто на раз-два-три настраивается и в пару кликов соединяется с интернетом только с модемом телефона, а CDMA-модем не видит в упор :(
Да, конечно же, на анализ ситуации это не тянет, как по количеству, так и по качеству. В этой заметке я немного пробегусь по двум шрифтовым хостингам (вообще-то, это название я придумал сегодня утром, но, я не удивлюсь, если так их называют и другие). Но перед этим я обрисую вопрос для тех, кто не в курсе происходящего. Заметка большая, потому что я не совсем определился с целевой аудиторией.
Для тех, кто занимается «сайтостроительством», либо каким-никаким веб-дизайном в интернете. Например, как я, облагораживает свой блог, делая его неповторимым и приятным для глаз.
Я долгое время был «как то не в курсе» происходящего. Ну, появилась еще одна разновидность OpenOffice, ну и что? Мало ли их было? Вот, например, Lotus от IBM я использовал долгое время. Сам OpenOffice, как говорится, «не фонтан», а поделки на его основе — ничуть не лучше. Почему же я «такой злой»?
Наверняка вы что-нибудь слышали об операционной системе Linux. Возможно, даже использовали (или используете сейчас) один из дистрибутивов. Так получилось, что после многолетних скитаний я крепко-накрепко «подсел» на Linux Mint. Не так давно вышла новая, 11-я версия этого замечательного дистрибутива. Я решил обновиться с 10-й версии и заодно рассказать вам, как можно установить Linux Mint на ваш десктоп (или ноутбук).
Всё началось с форума. Как-то раз, читая новые темы, наткнулся на тему «Выгуглен» [1], в которой давалась ссылка на весьма занятный игровой рассказ [2] с таким же названием. В рассказе обыгрывалась тема недалекого будущего, когда Google не только «всё про нас знает», но и наделен безграничными полномочиями, по сути, является последней инстанцией в вопросе твоей жизни. И, ведь, всё чинно и законно. Всё как сейчас…
Тема эта не нова, нет-нет да проскакивают подобные сообщения. Можно в очередной раз посмеяться и сказать «Какой вы мнительный, товарищ!» и закрыть глаза на всё происходящее. Можно, наоборот, сторониться Google как чумы. Но крайности всегда остаются крайностями, а истина… она где-то рядом.
В интересное время живем! Технический прогресс понемногу проникает в широкие массы населения, никогда об этом и не слышавшие. Что такое сервер? Многие скажут, что это такой шкаф, или специальный компьютер, стóит кучу денег, очень мощный, предназначен для массового хранения информации размером в несколько сот терабайт. Некоторые добавят, что у сервера нету мышки, клавиатуры и монитора. В общем, сервер — это что-то не из обычного, повседневного, мира.
Мне очень понравился этот альбом, и я с удовольствием слушаю его до сих пор. Что еще можно сказать, лучше послушайте сами. Единственно, слушайте на нормальных колонках или наушниках — саунд замешан на балансе высоких и низких звуков.
Стиль альбома: rock gothic alternativerock elettronic gothicrock
Лучшие композиции, по моему мнению, There's No End и Goodbye.