gdbus examples

Известная шина DBus может использоваться из разных языков программирования. Это делается через так называемые "Bindings". Для Гномовых библиотек "биндинг" уже второго поколения, и теперь входит в фундаментальную библиотеку glib.
Прежде на "биндинг" предыдущего поколения была неплохая документация в виде "учебника" с главой, посвящённой dbus-glib. С gdbus же творится что-то непонятное: ни примеров, ни учебника не найдёшь даже гуглом ;)
Впрочем, здравый смысл подсказал, где искать: в исходниках! Там несколько тестов и примеров использования. Документация, как обычно, доступна на сайте Гнома.

Мысли о мышлении

Некоторые коллеги избегают подобных публикаций, а мне в своё время эта книга помогла лучше понять себя и свои мотивации.
Вот этот труд: http://progstone.ru/kartostroenie.htm .
Именно к построению карт относятся многие из моих Записок. Именно к нему относится вопрос "How it's made?"

зачем нужны "сопроцессоры" в телефоне?

(Уже скоро год, как в черновиках лежит тема "Как устроен телефон". Эта тема связана с моим желанием разобраться, как он устроен и как работает (в деталях). Надеюсь, что в обозримом будущем, таки, напишу, хотя бы коротко, в чём успел разобраться.)

По поводу "сопроцессоров" — это я так назвал некоторые относительно независимые элементы устройства, которые работают как бы сами по себе.
Вот некоторые примеры:

1. GSM-модуль. Этот модуль представлять не надо. Он есть у любого GSM-телефона. Скажем, в старом каком-нибудь телефоне (глупофоне), например Motorola C115 он является единственным CPU и выполняет функции как GSM-терминала (общааясь с GSM-сетью), так и функции пользовательского интерфейса.
   Мне кажется, это и является причиной ограниченной функциональности, т.к. real-time-задачи GSM плохо сочетаются с произвольными программами, которые хотел бы запускать пользователь.
   "Рулит" этим процессором RTOS, например, VxWorks.
   Ещё добавлю, что иногда китайские производители телефонов упоминают этот модуль, как "второе ядро процессора" в такой формулировке: "Dual core 65nm ASIC: ARM1176JZFS 650MHz + ARM1176JZS 507MHz", хотя ничего, кроме GSM-стека там "не крутится". Впрочем, технически, это действительно второй процессор на SoC-е.
2. GPS-модуль. Во многом находится в том же положении, что и GSM. (Конечно, GSM — это не только собственно GSM: это 3G, CDMA и т.п.)
3. Вспомогательные DSP. Тут довольно большое разнообразие. DSP нельзя назвать универсальным CPU, но они так же относительно независимы, то есть работают в своём режиме и со своими программами и данными. В конкретных моделях примером могут послужить различные "железные" кодеки, такие, как H.264 и AAC.

Модули работают независимо, и потому имеют некоторые особые аспекты:

1. Как правило, имеют собственные программы, которые берутся из знакомых нам "прошивок". Если Вы пользователь Linux, то познавательно взглянуть в папку /lib/firmware/. На настольном линуксе у меня там сотни файлов, а на Nokia N900 целых 8!
2. Эти прошивки отнюдь не являются частью Linux, и чаще всего бывают проприетарными. От этого, до недавнего времени, страдал проект OpenMoko, в котором, кажется, единственной закрытой частью была именно GSM-прошивка. Однако проект osmocomBB, вероятно, закроет эту проблему.
3. Взаимодействие CPU с этими модулями осуществляется через электрические протоколы низкого уровня (гораздо ниже, чем, например, PCI), к примеру I²C и 1-wire, через GPIO-контакты SoC. В некоторых случаях это взаимодействие на уровне Serial line, как с GSM и GPS.

В целом, наличие этих модулей, с одной стороны, увеличивает цену конечного продукта, а с другой — увеличивает его привлекательность для потребителя. К примеру, кодек H.264 разгружает центральный процессор и проделывает ту же работу, например, по декодированию видео, потратив значительно меньше энергии. По этому поводу у Apple и Adobe был даже небольшой скандал.
Поддержка функциональности этих модулей в Linux часто отстаёт: как правило, гораздо легче "завести" процессор и экран, чем всю периферию.

Манжеты не хватило бы, чтобы вместить весь этот текст. Так что "закругляюсь".

о пользе netcat &Co

Внезапно понадобилось получить сетевое соединение по X11 от коммерческого юникса. Однако, из соображений безопасности TCP-порт X-server-а закрыт. Как быть?
Первый порыв — "где там эта опция включается"? Но это не очень-то практично: чтобы получить возможность на 5 минут, придётся выходить и входить в сеанс.
Но есть такой чудо инструмент: netcat. Это то же, что cat, но работает не с файлами, а вернее, не только с файлами, но и с сетевыми сокетами. socat — это его "внучек". С ним решение простое и элегантное:

socat UNIX:/tmp/.X11-unix/X0 TCP-LISTEN:x11

Рекомендую!

голова отдельно, туловище отдельно

Как бы это курьёзно ни выглядело, но в встроенном Линуксе встречаются ситуации, когда прошивка операционной системы берётся из одного источника, а ядро — из другого. Одна из предпосылок для подобных ситуаций: коммерческий (как правило) поставщик прошивки, у которого (очень часто) встречаются недоработки, которые решаются (благодаря ОперСорсу) отдельно собранным ядром Линукс.
К чему я веду? а к тому, что задача портирования Линукса распадается на две "почти ортогональные": ядро и "userspace". И получается, что, в общем-то, можно выбирать upstream ядра и всего остального по-отдельности!
Как то: собирать ядро из Openembedded, а всё остальное брать из полюбившегося дистрибутива (а хоть бы  из того же ALT, как это уже сделал один АЛьТовец)!

Intex: demand MORE!

Уже год, как приобрёл Intex IT-HDP252SA.
  + медиа-плеер по цене USB-SATA mobile rack.
  - китайский.

Честно говоря, это не тот случай, чтобы сказать "не гонялся бы ты, поп, за дешевизной". Поскольку, как USB-SATA он работает "на ура".
А вот как медиа-плеер — м-ну....
  + выходы: композит и VGA
  + поддержка кодеков MPEG4.
  - переключение между звуковыми дорожками только на MPEG2 (aka DVD)
  - субтитры: угадайте, в какой кодировке? Конечно же, не в кириллической!
  - через некоторое время работы (особенно, если видео "тяжёлое"), от перегрева выключается. В планах поставить радиатор.

И, наконец, по сути: разобрав устройство, выяснилось, что внутри чип ESS ES6430FAA. Пойду рыскать в инете, на что он способен. (А хорошо бы его, вообще, разогнать, чтобы не тормозил на "тяжёлом" видео).

migrate custom GNOME3 keybindings from GConf to dconf

Quite natural need but was not implemented by GNOME team. Ok, can do it on our own!
1. Get em' from GConf:

cd `mktemp -d`
gconftool-2 --dump /desktop/gnome/keybindings | sed -n '/<key>custom/,/<key>[^c]/ p' > 1

2. Next, cut off xml garbage:

cat 1 | grep '<string' | sed 's|^.*<string>||;s|</string.*$||; s|&quot;|"|g; s|&lt;|<|g;s|&gt;|>|g' > 2

3. Now take these command/binding/name triplets into the dconf-compatible form:

i=0 ; while read v; do echo "[org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom$i]" ; echo command=\'$v\' ; read v ; echo binding=\'$v\' ; read v ; echo name=\'$v\' ; i=$(($i+1)); echo ; done < 2 > 3

4. Yau! Get it into the dconf!

dconf load / < 3

5. Now fix the custom-keybindings key in org/gnome/settings-daemon/plugins/media-keys

dconf write /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings `egrep '^\[' 3 | sed "s|\[|'/|;s|\]|/'|" | tr '\n' , | sed 's|^|[|;s|,$|]|'`

That's it!