appliance, appliance, appliance, appliance!

Все знают, что наше время — время быстрых решений. Решение, которое внедряется больше недели-двух в IT — уже "большой проект".
Для поддержания IT-инфраструктуры компании нужны всякие серверы: шлюз, DNS, файл-сервер, почта, домен и т.п. Много всего. Традиционный админский подход: разворачиваем сервер на любимой ОС (юниксоид "венду" поставит только в крайнем случае), после чего настраиваем нужный сервис в этой ОС.
Важнейшие недостатки таких решений:

1. Неочевидность администрирования, особенно для слабо подготовленных  администраторов. Лучшее, что тут может помочь — инструкция, написанная человеком, который разобрался (то есть нужно заставить человека задокументировать этот сервер).
2. Как правило, в этом случае бывает непросто сохранить конфигурацию этого сервера. А уж вычленить, что конкретно настраивалось — почти нереально. (конечно можно сделать tar cf etc.tar /etc , но это далеко не всегда является решением: например, сервисы, запускающиеся в chroot живут по другому адресу. Пример: /var/lib/bind/etc ) .

Пришёл технический прогресс и принёс, на нашу радость:

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

Теперь нужное ПО (или нужный сервис, или "серверное приложение") можно получить в виде этого самого Virtual Appliance с временем установки и развёртывания ненамного больше времени копирования файла по сети.

Вывод: современные сервисы стали немного ближе к неподготовленным людям. Нужен сервис xyz? Устанавливаем образ в гипервизор, запускаем, и заходим через веб-интерфейс. xyz с человеческим лицом. Никаких creepy commandline для тех, кто к этому не готов.
У этих appliance есть ещё один плюс: его тонкой настройкой на уровне ОС занимается тот, кто лучше всего знает, как это сделать: разработчик, и делает это ... до того, как appliance попадёт к вам.
  + (часто) встроенный мониторинг системы
  + (часто) продуманное резервное копирование
  + ещё много чего

не-howto

"Google it!" "Прогугли это!" — эти фразы уже прочно вошли в лексикон.
Частенько, когда человек идёт что-то "гуглить", он идёт за рецептом. Вбивает проблему (или задачку) в строку поиска, и пытается выудить ответ в виде пошагового руководства. В линуксовом мире подобные рецепты известны под термином "howto".
Реже случается, когда человек идёт за знаниями. То есть не за ответом на вопрос "как это сделать", а за ответом "как это работает".

Я пришёл к выводу, что не очень настроен выдавать рецепты. Мне интереснее рассказать, "как это работает", и посмотреть, как это понял слушатель.

о сенсорных экранах

Недавно прочёл статью в Wikipedia: Сенсорный_экран.

Хочу поделиться выводами.

1. Разновидностей сенсорных экранов великое множество. Но, как обычно, в жизни можно встретить лишь две-три.
2. Те, что в ходу уже с десяток лет — это резистивные. Их особенность: лучше всего ими пользоваться с помощью стилуса. Впрочем, на нажатие пальцем экран тоже нормально реагирует. Но не очень надёжно работает "нажать и провести", как например, для листания списка.
3. Те, что используются сейчас в "пальцеориентированных телефонах" — это ёмкостные (с вариациями). Особенность этих экранов, кроме "пальцеориентированности" — поддержка нынче модного "multi-touch". В том смысле, что по своему устройству экран может выдавать несколько позиций прикосновения одновременно. Но чтобы это реально работало, нужно, чтобы multitouch поддерживал контроллер сенсорного экрана и его микропрограмма (в т.ч. его драйвер). Так что не любой телефон с ёмкостным экраном является при этом multitouch.

К чему эта информация? зачем? Тут есть два ответа:

1. На экран стоит обратить внимание в некоторых случаях при покупке телефона. Резистивные экраны встречаются в старых моделях и в китайфонах. Но для управления пальцами ёмкостный значительно комфортнее.
2. Мне думается, что столь сильное отличие сенсорных экранов разработчик пользовательского интерфейса обязан воспринимать, как различные устройства ввода информации. Серьёзно. То есть пользовательский интерфейс для резистивного экрана может и даже должен отличаться от интерфейса для ёмкостного, как отличаются интерфейсы (кто знает) WM5 и WM6.

Один большой секрет "китайфонов"

Что такое китайфон (или китафон), для тех, кто не знает? Вот неплохое место, чтобы узнать.

Немного лирики:

Итак, придите, например, ТЦ "Студент" в Алма-Ате, или в любое другое аналогичное место в любом городе, и увидите довольно широкий выбор китайфонов. Эти телефоны имеют приятный дизайн... по той простой причине, что дизайн разработан лидерами отрасли: HTC, Nokia, Sony, Apple и т.д. То есть выглядят телефоны, как распространённые модели: iPhone, всякие HTC, всякие Nokia. Два больших отличия: как правило телефоны поддерживают 2 SIM-карты и показывают TV! Но если включить телефоны, то почти во всех мы увидим идентичный один к одному интерфейс!

Вывод: при большом разнообразии внешнего вида, нутро у них одно-образное. То есть все они буквально "разливаются из одной бочки".

 Немного поразмышляв я пришёл к следующим выводам:

1. Возможно то, что "позаимствованный" дизайн: как наружный, так и внутренний, это просто подход "зачем изобретать велосипед".
2. Но, как я понял по тому, что пишут в интернете, некоторые продавцы используют сходство, чтобы продать эти телефоны, как оригиналы. Будьте бдительны! красная цена этим аппаратам никак не выше 100-200 американских условных единиц.

А теперь о технике:

1. Процессоры у них, как правило, производства компании Mediatek: MT6235, MT622x, MT621x. Дёшево и практично. Детали позже.
2. ОС (а и у обычных телефонов, как правило, есть какая-то Операционная Система!) Nucleus RTOS. Впрочем, уже есть и сматфоны: на Android и Windows Mobile. Представьте себе, двухсимочный смартфон! Китайцы впереди планеты всей!
3. Интерфейс у многих сильно напоминает iPhone. Впрочем, различия видны с первой минуты.
4. К сожалению, часто в погоне за дешевизной, производители ставят экстремально дешёвые компоненты: хрипящие динамики, резистивные сенсорные экраны и т.п.

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

В общих чертах - всё. Но тема с большим потенциалом, на мой взгляд, поэтому ждите продолжения.

Грабим и конвертим

Задача довольно типичная: сграбить видео с камеры Mini-DV и получить что-нибудь удобоваримое (будем считать эталонным выходом DVD, хотя, конечно же, каждому своё).
Традиционное решение --- то, что я видел, что делают другие --- это:

1. использовать kino для того, чтобы списать содержимое ленты на жёсткий диск (как говорят, "сграбить" в файлы *.dv)
2. использовать ещё одну GUI-программу, чтобы сконвертить эти файлы в то, что нужно

Такое решение неуклюже: использование графических оболочек, кучи места для промежуточных файлов. Поэтому поставлю задачу: в командной строке сделать всё за один проход без промежуточных файлов. Амбициозно? надеюсь, что да. Реально? совершенно точно: ДА. И это --- хорошая демонстрация unix-way.
С чего начну? с инструментария, очевидно. Попробуем так:

• dvgrab --- "грабит" из командной строки
• ffmpeg --- прекрасно и гибко конвертит

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

$ ffmpeg -i mov016.dv -vn -acodec copy /tmp/1.wav

Получается WAV с одной дорожкой аудио, что и требовалось.

Итак, несколько кирпичиков, из которых я построил решение:

• Простая конвертация файла видео в формат DVD (vob):

  $ ffmpeg -i mov016.dv -target dvd mov016.vob

• unix-way ffmpeg: использование pipe-ов:

  $ ffmpeg -i mov016.dv -vn -acodec copy -f wav pipe: > /tmp/1.wav

• заменить звуковую дорожку при конвертации:

  $ ffmpeg -i mov016.dv -i /tmp/1.wav -map 0:0 -map 1:0 mov016.avi

А теперь полностью задача и моё решение:
Задача: сконвертить готовый MiniDV-граб, записанный на DVD. При этом, почему-то, конверторы считают, что звук имеет частоту сэмплирования 48кГц (должно быть, это граббер напортачил). Надо вернуть звук в правильные 32кГц. (Это удалось выяснить, выделив 20 сек. звуковой дорожки, и проанализировав звук в audacity)
Решение:

$ mkfifo /tmp/v/a ; for f in `ls /media/cdrom/`; do screen -d -m bash -c "ffmpeg -i /media/cdrom/$f -vn -acodec copy -f s16le pipe: > /tmp/v/a" ; idlewrap ffmpeg -i /media/cdrom/$f -f s16le -ar 32000 -i pipe: -map 0:0 -map 1:0 -deinterlace -target dvd $f.vob < /tmp/v/a ; done ; while true; do aplay ~/Documents/sound/Масяня/Па-ба-бам-па-бам\ \(типа\,\ труба\).wav ; sleep 30 ; done

Не хочу объяснять, как это работает. Кто не сможет разобраться, тем лучше пока не пытаться писать длинные выражения в шелле. Впрочем, уважая читателя, я приведу ту же команду в отформатированном виде:

mkfifo /tmp/v/a ;
for f in `ls /media/cdrom/`; do
  screen -d -m bash -c "ffmpeg -i /media/cdrom/$f -vn -acodec copy -f s16le pipe: > /tmp/v/a" ;
  idlewrap ffmpeg -i /media/cdrom/$f -f s16le -ar 32000 -i pipe: -map 0:0 -map 1:0 -deinterlace -target dvd $f.vob < /tmp/v/a ;
done ;
while true; do
  aplay ~/Documents/sound/Масяня/Па-ба-бам-па-бам\ \(типа\,\ труба\).wav ;   sleep 30 ;
done

Следующий шаг: добавить граббинг, уместив полный цикл в одну строку без промежуточных файлов.

iso_mount.sh : монтируем ISO-образ из-под пользователя

Задача: примонтировать ISO-файл(ы) без прав суперпользователя.

0. Устанавливаем пакеты fuseiso, cdrkit-utils (опционально notify-send и notification-daemon)
1. Кладём в $HOME/bin файл:

#!/bin/bash

MYMNT=~/mnt
VOLID=`isoinfo -d -i "$1" |
grep '^Volume id: ' |
sed "s|^Volume id: ||"`

if [[ $VOLID == "" ]]; then
VOLID=`basename "$1" | sed "s|\.iso$||"`
fi

VOLID=`echo "$VOLID" |
sed "s|[^[:alnum:] .,()-]|_|g"`

mount | grep -q "$MYMNT/$VOLID" && {
nautilus file://"$MYMNT/$VOLID"
exit 0 ;
}

mkdir -p "$MYMNT"
fuseiso -p "$1" "$MYMNT/$VOLID" &&
{ nautilus file://"$MYMNT/$VOLID" ; } ||
notify-send -u critical -i cdrom_unmount -t 60000 "Failed to mount $VOLID"

2. в файловом менеджере "открываем" файл iso этим скриптом.
3. отмонтировать можно командой `fusermount -u "%f"' (подставляем папку, куда монтировали в %f)

для операций 2 и 3 я использую nautilus и nautilus-actions. Если у Вас другой файловый менеджер (напр. KDE файло), в скрипте нужно заменить nautilus на него.

/data покорёжен, boot loop. Что делать?

Android-2.2
Ситуация: рискнул покорёжить /data (это раздел с пользовательскими данными на внутренней флешке). В результате - boot loop. Что делать?
а) перепрошивка не помогает *)
б) в recovery, в котором есть возможность форматирования /data, тоже не зайдёшь (можно зайти только из нормальной загрузки командой adb reboot recovery).

А есть ли выход?
Выход есть! и очень простой: вспоминаем, что recovery --- это тот же boot, только с другим initramfs (который не монтирует /system и всё такое). Поэтому просто переименовываем recovery.img -> boot.img и вшиваем. Загружаемся, форматируем /data, после чего вшиваем настоящий boot назад. Вот так просто...

*) по крайней мере, той прошивкой, которая была