Get Yourself High

Готовимся к новому Mac Pro. Вместо заключения.
Link - Fri, 07 Feb 2014 03:55:48 GMT
Все изыскания, описанные в этой серии постов привели меня к публикации статьи в Hard'n'Soft:
http://www.hardnsoft.ru/academy/theory_and_practice/29678/

Готовимся к новому Mac Pro. Часть 5. Sonnet Echo 15.
Link - Mon, 11 Nov 2013 05:50:30 GMT
Что-то так получается, что для других тем у меня есть другие места для публикации, а ЖЖ-ка стала редким местом публикации постов, которые некуда больше приложить :)

Продолжаем разговор о новом Mac Pro. Следующим ингредиентом является Sonnet Echo 15. Производитель так долго откладывает выпуск устройства, что аж до первой недели ноября на сайте продукта красовалась надпись "Shipping summer 2013", что упоминать о нем тут не хотелось. Теперь, по заверениям производителя, отгрузка начнется в начале января.

Чем интересен данный продукт? Он позволяет получить массу полезной коммутации (USB 3.0, Firewire 800, Ethernet, аудио, eSATA), вынеся пучок кабелей подальше от компьютера. В нем присутствует так мне необходимый Firewire, а так же есть DVD. Так же есть возможность установить HDD или SSD, что не менее важно, так как встроенный в Mac Pro накопитель PCI-E - штука очень и очень не дешевая.

Готовимся к новому Mac Pro. Часть 3. ExpressBox 3T.
Link - Sat, 31 Aug 2013 13:13:32 GMT
Вот руки дошли до третьей части подготовки к нашему Мерлезонскому балету - разрешению проблемы переноса карт расширения.
Что теперь уже было установлено в моем старом Mac Pro? UAD-2 Quad, MOTU PCIe-424, старый OEM-комплект Magma P7NE, на котором в придачу сидят PowerCore PCI mkII и пара стареньких UAD-1.
Нет, ну можно было бы конечно разщедриться на какой-нибуть UAD Apollo или Apogee Symphony. Все это требует немерянных трат денег при абсолютно аналогичном эффекте. Да, конвертеры в MOTU 2408mk3 не ахти, но я ими и не пользуюсь. А с точки зрения цифровой коммутации лучще пока ничего не встречал:
в production у меня 16 каналов идут в/из старенький Tascam DM-24, поканальная запись через встроенный в SPL Channel One конвертер по SPDIF, в postproduction - по SPDIF через встроенный в Presonus Central Station конвертер. Если что, Master Clock внешний, Lucid GENx192.
В общем, масса причин сэкономить денег и воспользоваться существующим оборудованием через Magma ExpressBox 3T.
Пришлось сделать небольшую доработку - вывести питание наружу для автоматического включения ящика с P7NE. Забыл пощелкать процесс доработки. Просверлил в PCIe-хосте P7NE дырку. Рвспаял кабель - с одной стороны Molex под ввод питания (внутри коруса), с другой - miniDIN-8.








Готовимся к новому Mac Pro. Часть 2. Pegasus R6.
Link - Mon, 19 Aug 2013 03:49:45 GMT
Mac Pro - штука очень не дешевая, по этому все что нужно лучше купить заранее. Сильно заранее. :)
Первым в списке стал Promise Pegasus R6.
Устройство я покупал на Amazon-е с таким расчетом, чтоб вместить стоимость в квоты беспошлинного ввоза таможенной декларации.
Когда закупал, даже как-то и не подозревал, что в устройство будут предустановлены диски на 1 Тб (комплектация PR601US), целиком рассчитывал на то, что диски поставлю уже здесь.
В итоге заменил комплектные одноблиновые диски Toshiba, которые де-факто являются OEM-ами Hitachi, на аналогичные трехблиновые на 3 Тб. Диски на 4 Тб покупать как-то экономически не целесообразно. Как только это сделал, тут же подключил к моему MacBook Air (это пока единственный компьютер у меня с поддержкой Thunderbolt). На первых двух дисках сделал зеркало на 3 Тб под долгосрочные данные, переезжающие с компьютера на компьютер, вроде всяких пофайловых резервных копий, архивов и всего прочего. На оставшихся дисках сделал массив 5-го уровня, на котором разбил два раздела, под операционные данные на 6 Тб и под TimeMachine на 3 Тб. По идее в такой развисовке под мои задачи хватит. :)
Общие впечатления: устройство работает очень и очень тихо! Даже не смотря на то, что в нем молотит орава из 6 дисков на 7200 rpm. Вибраций нет. Немного замудрили конфигурацию, пытаясь привести логическую модель массива к тому, что есть на Adaptec-ах, но пока еще очень далеко. Производительность на уровне. Очень рекомендую сразу обновить прошивку на самую последнюю, с предустановленной наблюдались некоторые проблемы при выходе компьютера из sleep-а.
Начал переливать данные... По AFP и 802.11n на терабайт по прогнозу Finder-а должно уйти более 2 дней, так что я бросил пока это дело.














Update:

В качестве послесловия. На рынке еще есть интересная корзина от Areca на 8 дисков - ARC-8050. Хоть у нее и весьма достайная производительность, мне она не очень понравилась, нет концептуальной целостности устройства: все конфигурирование производится через LAN. Это при наличии подключения по Thunderbolt.

Готовимся к новому Mac Pro
Link - Wed, 19 Jun 2013 03:57:00 GMT
Совсем недавно случилось долгожданное событие - Apple анонсировала новый Mac Pro. Устройство кардинально отличается от предыдущих моделей на Intel, по этому миграцию на новое устройство следует детально спланировать, а если еще учесть его стоимость, как у чугунного моста, то миграцию нужно планировать сильно заранее.
Не скажу, что напишу что-то новое. Все эти мысли витали у меня в голове и ранее, но в расчете варианта переезда на MacBook Pro (напомню, что в настоящий момент я использую в основном мой 5-летний Mac Pro 3.1 early 2008 и MacBook Air 11" 2012). Тем не менее, анонс нового устройства окончательно расставил все точки над i и разрешил мою дилемму "покупать или нет".

И так, что имеем:
  • 3 дополнительных диска SATA под TimeMachine и архивы данных в RAID 1, унаследованных со старых компьютеров. Естественно, что можно бы было все это перетащить на забитый дисками домашний сервер на Linux, ну и активнее пользоваться TimeCapsule, но это не наш способ. + еще аудио-библиотеки, требующие быстрого стриминга.
  • 3 платы PCI-Express. Тут и про-аудио интерфейс, и DSP, и даже мост PCI от Magma. Без этого багажа я совсем никуда. А апгрейд данного оборудования приведет к еще большим затратам.
  • Некоторое количество устройств с FireWire 400 (PowerCore, Korg, Tascam) с хабом от Belkin. Их тоже нужно подключить.
  • Наконец, хочется все-таки обойтись минимальным количеством кабелей, торчащих из компьютера.

Теперь соображения о том, как будем решать. Кстати, решение вполне применимо и для MacBook.
  • Для SATA закупаем Promise Pegasus R6 на 6 дисков. Во-первых мигрировать туда диски будет дешевле, чем покупать накопитель PCI-E SSD космических объемов, да и диски имеются в наличии. На 6 дисков, чтоб потом не жалеть, что не хватило слотов и не тратиться на еще одно устройство.
  • Для плат PCI Express меняем шило на мыло - у Magma для этого есть замечательный продукт Magma ExpressBox 3T. Про совместимость моих плат я уже все выяснил.
  • Для подключения существующей периферии Firewire есть оригинальный адаптер Apple Thunderbolt Firewire Adapter.
  • Наконец, вопрос с организацией кабелей. Во-первых думаю на тему нормальных 10-портовых хабов USB 3.0.
  • Ну и во-вторых. Я пользуюсь KVM-переключателями и штатным звуком для мультимедиа, Thunderbolt Display не рассматриваю, но хочется иметь подключение всего одним кабелем, как в случае последнего. По этой причине я задумываюсь о Matrox DS-1/DVI. Устройство передает обычный видеосигнал с видеоадаптера компьютера по схеме Daisy-Chain, но в добавок на борту есть контроллер USB и аудиоадаптер.

Оставлю этот пост без выводов. Просто для размышления и информации.

Update:
Еще одно устройство, на которое имеет смысл обратить внимание - Sonnet Echo 15. Но, к сожалению, несмотря на обещания производителя, отгрузка так еще и не началась...

IGMP Snooping на Linux KVM
Link - Fri, 14 Dec 2012 17:59:21 GMT
Перенеся домашний сервер на Linux KVM столкнулся с некорректной работой MediaTomb: через некоторое после перезапуска время плееры в локальной сети переставали видеть программу. Изначально грешил на слабую поддежку MediaTomb в последние пару лет. Заменил на MiniDLNA, но ситуация повторилась.
Очевидно, что проблема связана с multicasting-а, который используется протоколом SSDP, в локальной сети. Известная проблема связана с реализацией IGMP Snooping-а на интерфейсах bridge в версиях ядра Linux 3.x.
Пока тестирую следующее решение, отключающее snooping:

$ cat /etc/network/if-up.d/bridge

#!/bin/bash

if [[ $IFACE =~ br[0-9] ]]
then
echo 0 > /sys/devices/virtual/net/${IFACE}/bridge/multicast_snooping
fi


Заодно поставил miniSSDPd, пропатчил MediaTomb и теперь использую его совместно с MiniDLNA.

KVM
Link - Mon, 10 Dec 2012 14:06:45 GMT
Виртуализаця серверов - тема нынче весьма и весьма актуальная. Помимо оптимизации использования аппаратных ресурсов серверов, это еще и экономия как капитальных, так и операционных затрат.
В моем ведении находится с десяток серверов-супервизоров с порядка пятью десятками виртуальных машин.
Все они работают в связке Linux KVM + QEMU + VirtIO + libvirt.
Долгое время был вне тренда лишь домашний сервер. После долгих и непродолжительных экспериментов c Linux-ами со времен компьютеров на процессорах Pentium 1-го поколения, устоявшаяся продуктивная конфигурация в режиме 24х7 появилась у меня на процессоре P3-500. Конечно. в те времена никакой речи о нормальной виртуализации не было, по этому сервер (ОС + окружение) несколько раз мигрировали из одной железки в другому в неизменной парадигме: одна ОС - одно железо.
И вот, в очередной раз очередной комплект железа (Core 2 Duo, 3 Gb RAM) начал умирать. Окончательно эту конфигурацию поканали работы с постоянным отключением света у Мосэнерго. И, как обычно, вынуждено в срочном порядке мне пришлось закупать новое жедезо (слава богу, что половина из того что было нужно, наскреблась по сусекам). Вот, наконец, возможности и необходимость наконец пересеклись - старый сервер по плану дожен был виртуализоваться.
Большая часть работы прошла как по маслу: с помошью dd с жесткого диска снят слепок, сконфигурированые VLAN-ы перенесены отдельными бриджами, протащены последовательные порты, переконфигурирован mdraid, пересобран initrd. И вот тут меня настиг virtfs.
Дело в том, что долгосрочные данные у меня на старом сервере находились на аппаратном массиве RAID5 за контроллером Pronise. В запасниках у меня был еще Adaptec и еще немного дисков, на которых были данные. Тащить все это хозяйство на новый массив слепком не было резона. Можно было бы и сделать некоторый изврат вроде NFS или SMB-шары, но это именно изврат. VirtFS для этой задачи подходит как нельзя кстати.
VirtFS - это достаточно свежая поделка в QEMU. В гостевой ОС для нее отображается новое устройство, а в ядро ОС включена поддержка сетевой файловой системы 9P (разработанной в рамках проекта Plan 9).
Для Debian Squeeze сейчас все это хозяйство доступно в BackPorts. Пишу эту простыню, чтоб обратить внимание на несколько важных моментов информационной безопастности. Большинство формумов показывает явное недопонимание проблематики у контингента.
И так, у host-системы есть две системы организации разграничения доступа - passthrough и mapped. Для гостевой - user, uid, client. Определяют они, как для VirtFS будут определяться фактические права для доступа к файлам.
Основаная заковырка связана именно с host-системой, по этому я остановлюсь на ней поподробнее. Passthrough - это режим, когда UID, GID и аттрибуты host системы отображаются на гостевую 1:1. Пока я экспериментировал с ней, напоролся на несколько важных граблей: важно понимать, что сами идентификаторы (а сдедовательно пользователи и группы) должны иметься в обоих системах, иначе при авторизации пользователя и делегировании QUEMU прав операция в большинстве случаев неуспешна, а результат доступности данных не очевиден. Все это приводит к тому, что большинство пользователей, не разобравшись в проблематике, лепят просто o+w на все файлы на общей папке. То, что это epic fail в безопастности - говорить не стоит. Второй неприятностью является то, что QEMU должен работать под root-ом, чтобы иметь возможность оперировать setuid / setgid. Иными словами, passthrough нужен и эффективен только тогда, когда вся инфраструктура имеет общую директорию пользователей, а непосредственное применение прав на файловой системе хранилища необходимо. Для всех остальных случаев лучше использовать предназначенный для этого инструментарий вроде NFS или SMB.
Режим mapped куда более интересный и нам подходит куда больше. Идея его в том, что на файловой системе host доступ должен соответствовать эффективным правам доступа QEMU, права доступа гостевой системы сохраняются в расщиренных атрибутах файла. Недопонимание того, что просто необходимо разрешить на файловой системе использование расширенных атрибутов (указать опцию user_xattr в /etc/fstab) связано в 100% случаев с неработоспособностью этого режима у пользователей, а соответственно, его редкого использования. Режим mapped, на мой взгляд, наиболее предпочтителен для ситуаций, аналогичных моей.
С клиентскими политиками все просто: user - передавать эффективный идентификатор пользователя в QEMU, uid - передавать конкретный идентификатор, client - не проверять эффективные права на гостевой системе, используются только эффективные права QEMU.
Вот, вкратце, все.

GCC vs LLVM-GCC
Link - Fri, 06 Apr 2012 13:27:06 GMT
Уже давно и неоднократно писалось, что LLVM-GCC проигрывает в производительности скомпилированного кода. Везде, как правило, указывалось на незначительные провалы в производительности и лишь в некоторых сложных тестах - до 50%.
Но, блин, я не думал, что 50% провал будет на таких простых задачках, как тут. 50% слив. А это означает, что LLVM-GCC не умеет даже при вклченой оптимизации нормально раскладывать все по регистрам и нормально лепить "короткие" переходы.

DS203
Link - Mon, 26 Sep 2011 18:02:14 GMT
Сегодня наконец пришла посылка с осцилографом DS203, он же DSO Quad. Про качество ничего пока сказать не могу, но конечно, подкупила цена, да еще с учетом того, что мне DealExtreme был должен денег. :)
Конечно. на DX комплектация победнее, чем у SeeedStudio (см. обзор от МК90), поставка OEM, но имеющиеся щупы однозначно лучше.
Прибор совсем лилипусичный! Я сначала даже сел на измену, когда распаковывал - думал, упаковка с аккумулятором, а прибор сперли. Боюсь представить, какого размера DSO Nano v2.
Я, правда, заранее подготовился и купил в SeeedStudio несколько переходников на BNC.







Феерический абзац с Роскомнадзором.
Link - Wed, 10 Aug 2011 02:41:02 GMT

Обзавелся я тут, значит, очередным трансивером в июле. Нужно зарегистрировать в Роскомнадзоре.
Раньше я пользовался услугой одного дядички - отдавал ему документы и его девочки-мальчики сами ездили оформлять разрешение на станцию с этой муторной процедурой. С нынешним разбродом (например, позывные до сих пор не дают и я не могу повысить категорию из-за этого), дядечка пока такой курьерской услугой не занимается. Так что теперь все самому.
Выяснил, что на rsoc.ru есть форма для подачи заявления в электронном виде - чтоб лишний раз туда не мотаться, я ее заполнил и стал ждать неизвестно чего.
Прошел практически месяц, никто не пишет и не звонит. Проверяю статус заявки на сайте: "заявка передана в электронную систему Роскомнадзора". Ну пипец какой-то, сайт уже не электронная система. Там же дан телефон справочной.
Звоню. Объясняю девушке в справочной, что частоты выделять мне не нужно, всего лишь зарегистрировать РЭС. в итоге договорились до того, что мне нужно позвонить в "отдел".
Еще неделя уходит на то, чтобы в этом "отделе" сняли трубку. В общем, меня отредиректили в справочную московского отделения Роскомнадзора. Звоню туда. Опять описываю девушке (теперь из московского филиала) ситуацию. Дает номер тетеньки, занимающейся электронными заявлениями. Звоню ей. Та раздроженным голосом завляет, что я уже второй за день умник, который звонит по этому поводу и к ней (не смотря на поданное в электронном виде заявление) это никакого отношения не имеет. Правда, дала телефон в "отдел", теперь уже региональный. Фиерия продолжается.
Звоню в "отдел": "А вы нам бумажные копии заявлений привозили? Откуда мы знаем о том, что вы завели электронные? Вот привезете - узнаем". Занавес.
Надо сказать, что все девушки, кроме той, что на электрических заявках, весьма вежливы. Хоть какой-то прогресс в госучереждении.

Posted via LiveJournal app for iPad.


Link - Mon, 01 Aug 2011 16:20:07 GMT
ВЕДОМОСТИ

Насколько Вы москвич?

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

Top 10 must-have приложений для iPad от меня
Link - Thu, 07 Jul 2011 04:42:05 GMT
  • MobileRSS HD - великолепный клиент для Google Reader
  • Twitter - оригинальный клиент Твиттера прекрасен!
  • MyPad+ - для Facebook лучще ничего е видел
  • 1Password Pro - куда же без него, особенно при нынешней кросплатформенности приложения и DropBox в качестве хранилища
  • Forum Runner - не скажу, что он прекрасен, но при общении на форумах он сильно облегчает жизнь
  • Wikipanion+ - великолепнейший клиент для WiKi, имеющий возможность планировать чтение "на потом" и читать в оффлайне
    FlickrStackr - клиент для фотохостингов
  • eBay for iPad и Amazon WindowShop - с ними вы себя спросите, как же раньше обходились без них :)
  • Evernote - заметки, WebClip-ы... Последнее, на мой взгляд имеет некоторое преимущество по сравнению с InstaPapper и Read It Later Pro, потому что сохраняет в облаке содержимое, а не закладки, что полезно при сохрании страниц из Интранета или с безответственных сайтов :)
В добавок отмечу несколько специфичных для разных предметных областей приложений, которые мне так же очень понравились:
  • MacLoggerDX HD - лучший логгер для любительской радиосвязи с синхронизацией журнала с "большим" MacLoggerDX, а так же возможностью работы с радиостанцией через него же посредством Bonjour
  • OpenAPRS-xL - клиент для доступа к услугам APRS
  • ReBirth for iPad - клон знаменитого Rebirth от Propellerhead Software
  • KORG iElectribe - проммная реализация KORG ELECTRIBE·R
  • FL Studio Mobile HD - версия Fruity Loops для iPad
  • Koder - редактор кода с подсветкой синтаксиса,поддерживающий iDisk, DropBox, FTP

Вот теперь Garmin люблю я, вот теперь Garmin хвалю я!
Link - Tue, 05 Jul 2011 19:09:35 GMT
Давича копаясь на тему waypoint-ов по APRS, а соответственно, навигаторов, которые бы могли работать с APRS, наткнулся на используемую в штатах связку Garmin Nuvi 350 + Kenwood TM-D700 через маленькую поделку GTRANS Cable от Argent Data Systems.
Дальнейшие изыскания привели меня к тому, что в своих навигационных продуктах Garmin изготовил Fleet Management Interface, причем активно и в открытую развивает его.
Конечно, цена на кабель, особенно в версиях для новых устройств - кусачая, зато мы имеем несложный протокол поверх RS-232 и открырый SDK.
А самое главное - Garmin пошел на поводу у энтузиастов и начиная с версии протокола 2.50, устройства офицально (в версии 1 это было не официально) поддерживает управление waypoint-ами!
Ну предположим, с другой стороны у нас Kenwood TM-D710, имеющий отдельный интерфейс RS-232, который "кушает" NMEA и "сплевывает" waypoint-ы в собственном формате. А еще у нас есть данные из Интернет по камерам, постам и засадам, которые тоже достаточно часто (ежедневно) актуализируются. И заливать бы это дело удобно бы было со смартфона с помощью Bluetooth. Получается такая нехилая задачка по мультиплексированию и преобразованию данных на трех последовательных портах, хорошая задачка для Arduino на Mega 2560.
Пока писал, подумалось, что заодно можно и позиции друзей сливать из гео-социальных сетей. :)

Переключаем антенны на MFJ-993B с помощью microHAM Station Master
Link - Thu, 30 Jun 2011 03:47:04 GMT
Еще одна не совсем обычная интеграция приборов в шеке: у вас автоматизировано все управление с помошью microHAM Station Master, на столе стоит удобный пульт для него в виде PS/2 NumPad... а необходимо переключить коммутатор антенн на MFJ-993B. Собственно, причины использования коммутатора на MFJ-993B три: для второй антенны настройки в тюнере сохраняются отдельно, экономим на внешнем реле (зачем, если все равно есть встроенное), снижаем издержки качества сигнала - меньше побочной коммутации (разъемы, реле - на всем этом есть потери). Приимуществ, в общем, куча, а вот в концепцию автоматизированного управления и аскетичного рабочего места не укладывается. Что делать?
Нет, снимать штаны и бегать не потребуется. MFJ для нашего с вами удобства сделала проводной пульт дистанционного управления MFJ-993RC для этого тюнера. Сам пульт нам не нужен, но поскольку он прост до безобразия, мы воспользуемся его функцией коммутации антенн. Нога 8 разъема DB9 "Remote Control" у тюнера отвечает за переключение антенн. Замыкать ее следует на корпус разъема. Замкнутое состояние соответствует состоянию ANT1, разомкнутое - ANT2.
Что касается подключения к microHAM Station Master, для этого лучще всего подходят выходы B6 - B10, которые образуют отдельные коммутационные пары.
PS. Для автоматического переключения антенн кнопка ANT на тюнере должна быть нажата.

Вкусняшки для JavaScriptCore
Link - Wed, 22 Jun 2011 17:29:09 GMT
В кое-то веки решил поделиться некоторыми вкусняшками. :)
Если кто работал с WebKit или имел необходимость погонять JavaScript в своих приложениях знают, что одним из легко доступных движков является JavaScript Core от Apple, поставляемый в комплекте WebKit под большинством фреймворков.

В работе с движком есть одна особенность - за собой она тащит кусочек runtime-а от CoreFoundation, в частности строковые типы. При разработке кода на C разработчик не имеет вариантов и вынужден кругом использовать функции для работы с такими строками, что существенно перегружает код и снижает его читаемость. Если же мы обратимся к C++, то у нас найдется вполне элегантный вариант в виде класса-контейнера, скрывающего в себе реализацию JSStringRef:

class JSString
{
  public:
    JSString(const char* value);
    JSString(const std::string& value);
    JSString(const JSStringRef& value);
    JSString(const JSContextRef& context, const JSValueRef& value);
    ~JSString();
    operator JSStringRef();
    operator std::string();
    operator Glib::ustring();

  private:
    JSStringRef string;
};

JSString::JSString(const char* value)
{
  string = JSStringCreateWithUTF8CString(value);
}

JSString::JSString(const std::string& value)
{
  string = JSStringCreateWithUTF8CString(value.c_str());
}

JSString::JSString(const JSStringRef& value)
{
  string = value;
  JSStringRetain(string);
}

JSString::JSString(const JSContextRef& context, const JSValueRef& value)
{
  string = JSValueToStringCopy(context, value, NULL);
}

JSString::~JSString()
{
  JSStringRelease(string);
}

JSString::operator JSStringRef()
{
  return string;
}

JSString::operator std::string()
{
  size_t length = JSStringGetMaximumUTF8CStringSize(string);
  gchar buffer[length];
  JSStringGetUTF8CString(string, buffer, length);
  return std::string(buffer);
}

JSString::operator Glib::ustring()
{
  size_t length = JSStringGetMaximumUTF8CStringSize(string);
  char buffer[length];
  JSStringGetUTF8CString(string, buffer, length);
  return Glib::ustring(buffer);
}


Пример использования:

context = JSGlobalContextCreate(NULL);
JSObjectMakeFunctionWithCallback(context, JSString("dnsResolve"), dns_resolve);
JSObjectMakeFunctionWithCallback(context, JSString("myIpAddress"), my_ip);
JSEvaluateScript(context, JSString(proxyConfigureFunctions), NULL, NULL, 1, NULL);
JSEvaluateScript(context, JSString(script), NULL, NULL, 1, NULL);


Как можно заметить из примера, вся реализация управления временем жизни строки делегирована компилятору через создание на стеке анонимного экземпляра нашего класса-контейнера, код элегантен, не допускает утечек и прост для понимания для начинающих разработчиков. Вся сила C++ в элементарных "рюшечках".

Облако в массы!
Link - Sun, 12 Jun 2011 16:42:02 GMT
Я как-то смотрю на то что происходит вокруг и веселюсь. Лет 6-7 назад начал лабать толстых клиентов под сервисы для Symbian и всем пытался доказать, что на мобильных устройствах следует делать толстые приложения, соответствующие User Expirience-у платформы и компенсирующие низкую скорость и латентность передачи данных в радиосетях. Джобс вконце концов продавил это в мозги масс и теперь обходится без толстого мобильного клиента считается в среде интернет-сервисов неприличным.
Для прочих приложений издревле изготовленных под PC и даже под мобильные устройства ранее никто не задумывался о application continuity. То есть приложения мы имеем и там и там, а о том, чтобы как-то состояние синхронизировать между ними - не задумаывались. И вот свершилось Облако (в контексте application continuity)! Дошло. Apple обещает бесплатно, PlayStation Network в рамках подписки PSN+, да и самое интересное все равно ждать - приложения пока еще не готовы. Хотя прикольно, что хоть до кого-то дошло, что возможен такой вариант использования, если гамер режится в игру на PS3 и ему приспичило в сортир, можно перенесли плей на PS Vita и продолжить игру в туалете. Ну или в вагоне метро. И за это можно даже брать деньги. Посмотрите на IT 10-летней давности - этого ничего не было.
Кстати, большие дядьки в наших компаниях-операторах ходят и маяться: чуют, что "облако" в каком-то из проявлений нужно продавать, а в каком (помимо Office 365) - не поймут. Да и вооще, что есть "облако" им не понятно. И действительно?! :)
Соедующвя тенденция - очередное поколение развития социальных сетей. Слава богу, MySpace умирает - крайне кривой интерфейс и нечеткая концепция. А вот Цукерберг с Facebook продолжает удачно развиваться. И, как мне кажется, за счет интеграции с чужими сервисами, взращиванию приложений третьих сторон.
Пройдем мимо "Фермы". Какое-то время назад, когда Activision выпустил Guitar Hero 3, они реализовали некий простенький XML-интерфейс для получения информации по статусам игроков, не придавая этому большое значение. Народ активно его заиспользовал на всяких окогогеймерских форумах и сайтах. В то же время я разработал и опубликовал маленькое приложение на FB, которое отслеживает прохождения игроков за сутки и публикует это на стене FB. Через какое-то время интерфейс закрылся, но аналогичная потребность возникла в головах издателей и вот Rock Band и PlayStation Network засыпают мою стену достижениями в прохождении игр. И самое что интересное, функция ассоциации аккаунтов с FB появилась прямо из PS3.
Социализация вообще трансформируется как-то необъяснимо в последнее время. Sony пытается, похоже, изменить место PSN в процессе игры и максимально обозначить коммуникации между игроками за пределами домашней игровой консоли. В частности, релиз PS Vita обещает не только уже имеющийся в PS3 чат и инфо о статусе игры, но и некие нотификации вроде iOS-ных Push. Что это конкретно - пока не понятно. PS Vita - мобильное устройство с 3G.
Кстати, все последние гаджеты стимулируют спрос на услуги беспроводных операторов. Несколько лет назад человек с двумя SIM-картами смотрелся как полный гик, ныне чуть ли ни у каждого по отдельной карте еще в ноутбуке, iPad-е, скоро и в PS Vita. Назначенная пару лет назад стагнация продаж контрактов никак не прийдет - количество абонентов мобильных сетей уже превысило население страны, хотя, в какой-то мере, продажи спали. Интересно, когда же наконец доходы от передачи данных в мобильных сетях превзойдут доходы от трафика?
Социализация, облачные приложения, application continuity - все это многократно увеличивает потребление трафика. Очередная маленькая революция в ценах должна произойти, уже есть безлимитные пакеты мобильного трафика, наметились первые звоночки в ценах на роуминг при передачи данных. И вроде как все готово к очередной технологической революции, но как обстоят дела с юридическими аспектами? Конец анонимности, частной жизни и прочему?... Оставлю пока эту тему открытой...
Всем приношу извинения, что пост не содержит четкой структуры и выраженной мысли. Поток сознания, имевший целью обозначить существующие тенденции и дать вам задуматься о происходящем.

Очередной проект - "Туалетный контроллер"
Link - Tue, 24 May 2011 11:39:39 GMT
Идея реализации "туалетного контроллера" возникла у меня несколько лет назад, но только сейчас я созрел к реализации этого проекта.
"Туалетный контроллер" - что это такое?
Идея весьма проста. Это контроллер, который собирает околоводопроводную телеметрию, преобразует интерфейсы и выполняет некоторые привентивные действия, случись что. "Околоводопроводная" телеметрия - это показания счетчиков расхода воды, датчики утечки, температуры трубы горячей воды. Электронный монометр не помешал бы, но ценник кусается. Управляемыми устройствами должны стать нормально-закрытые электрические крапаны, перекрывающие поток воды, а при отключении горячей - маршрутизирущие поток в проточный нагреватель. Заодно все хотелось бы обернуть в RS-485 для того, чтобы синтегрироваться с контроллером домашней автоматизации ADI Leopard II, а так же компьютером для мониторинга, управления и снятия показаний - прежде всего расхода воды, его отправку на сайт ЕРЦ достаточно легко автоматизировать.
Наиболее продуманный сейчас момент - это замер расхода воды. Механические счетчики имеют герконовый импульсный датчик, дающий сигнал на каждые 10 литров. Так как снимать показания с механического счетчика нельзя, считать импульсы нужно непрерывно без прерывания. То есть считать на каком-либо контроллере не получится. У Maxim (Dallas Semiconductor) было замечательное решение на интерфейсе 1Wire - DS2423 - 2-хканальный счетчик с RAM. Уже пару лет как этот чип снят с производства. Похоже, что сменивниеся продакт-менеджеры в Maxim не просекли всей сути назначения этого чипа, сняв его с производства они предлагают на замену обычные 1Wire RAM. А ведь RAM в этом чипе вторичен, по-хорошему он нужен для того, чтобы сохранять состояние счетчика в момент последнего прочтения, что позволяет точно "снимать" телеметрию с каждого конктретного датчика вне зависимости от состояния контроллера, с помощью которого снимаются показания. Чип DS2423 можно найти на китайских складах по цене от $8 до $12, а Hobby Boards продает даже готовые решения на печатной плате с обвязкой и батареей питания за $28. Я выбрал последнее решение.
Пока-что снимать показания я собираюсь самодельным контроллером на базе Arduino Uno (AVR Mega168). Есть и промышленные решения, например контроллеры Poseidon, но цена вопроса, непонятки с счетчиками и отсутствие RS-485 в slave mode явно не в пользу этого выбора.
Рассматриваем вариант Arduino Uno. За коммуникации с 1Wire будет отвечать мост DS2482-100. Я вкурсе о программной реализации 1Wire в том числе и для Arduino, но помехоустойчивость такой непосредственной реализации сильно страдает. SOIC8, конечно, тяжело паять, но тут никуда не денешся. Единственный COM-порт Arduino Uno будет занят интерфейсом с компьютером, коммуникации RS-485 я планирую выносить на связку SC16IS750 + MAX482. SC16IS750 аппаратно реализует переключение направления передачи half-duplex для MAX482, аппаратно реализует адресные фильтры RS-485. Проблема SMD монтажа решается вот такой вот платкой от Sparkfun-а. Остается только на монтажной плате поставить разъемы да MAX482, благо есть в DIP-корпусе. RTC-часы на DS1307 доступны в виде готового конструктива.
Что касается исполнительных устройств, то тут пока определенности нет. Доступны разные варианты интерфейсов.
Продолжение следует...

Используем МКЭШ 14 для подключения антенны ФАП
Link - Fri, 20 May 2011 04:18:04 GMT
Совсем кратенький пост - полезняшка.

Антенна ФАП использует 16-проводную линию для питания и управления. Достаточно проблематично найти кабель, который бы имел достаточное сечение и количество линий. Отечественная промышленность выпускает кабели с достаточно экзотическом количеством линий даже для использования в отечественной технике.

И того, имеем антенну ФАП, которая "кушает" 16 линий и кабель МКЭШ 14х0.35. Его сечени (0.35) полне достаточно для питания анода и накала. Остается решить вопрос, как же подсоединить 14 линий без потери функциональности.

Детальное изучение схемы показало, что есть три вещи, которыми можно пренеборечь:
  • Наименьшая емкось в набивке. Етой линией вполне возможно пренибречь, если точность настройки в резонанс не стоит во главе угла. Дискретность этой настроки составляет где-то в районе 5 КГц, то есть несколько шире полосы SSB. Мне не очень хочется потерять такую точность.

  • Генератор шума. Наверное, это первое, о чем я подумал для исключения. Но если детально рассудить, получается, при выносе антенны за стены дома генератор шума является единственным способом ее диагностики. При его запуске помимо шума на резонансной частоте пульт управления показвает ток анода. В общем, не вариант.

  • Если детально изучить схему, две линии передают землю. Сделано это для удобства комутации "ручник/автомат". Вернее, для исключения единовременной работы двух схем управления - ручной и автоматической. Но так ли это критично?

Если хорошенько подумать, то все-таки объеденить раздельные цепи земли можно. Если это сделать, важно соблюдать только одно правило - на линиях автоматического управления не должно ничего передаваться при ручном управлении.
И того, теперь требуется 15 линий для управления антенной. 15 линию находим в виде добротной оплетки, которая имеется у кабелей МКЭШ.

RA6LBS K-98
Link - Wed, 18 May 2011 07:01:04 GMT
Попереписывался тут с Андреем RA6LBS по поводу его K-98.

Поговорили с ним о вариантах автоматизированного управления K-98 при помощи Station Master. Идея выглядит так:
У Station Master есть функция виртуальной поворотки, с помощью которой комманда, выдаваемая компьютером на установку угла поворота антенны, приводит к коммутации антенного переключателя на антенну, соответствующую направлению приема/передачи. Такая функция позволяет автоматически выбирать нужное направление работы прямо из логгера нажатием одной кнопки (предположим, что QTH корреспондента нам известен из его карточки на QRZ.com, которая "подтягивается" логгером автоматически).
В какой-то мере K-98 представляет собой набор таких антенн со всроеной функцией коммутации. Наша задача - этаким хаком без модификации оригинального блока управления антенны добиться автоматизированного управления. Изучение схемы блока управления подсказало решение.
И так, предположим, для управления антенной мы будем использовать порт B на Station Master. Этот порт разбит на две секции, физика второй секции (4 канала) ориентирована на работу в качстве секвенсора - имеет несколько раздельных парных выходов реле. Первые 6 каналов, в принципе, предназначены для BPF, но фактически любое реле из любой секции может иметь любое из трех (ANT, BPF, SEQ) назначений. Порт А так же не имеет жесткого назначения, тем не менее, общая линия у него на все каналы. Так что в нашей ситуации нам будет удобнее использовать порт B.
Сейчас в порт B у меня подключен самоизготовленный переходник на 4 RCA разъема для функции секверсера. Туда же имеет смысл припаять переходник для K-98.
Далее - про коммутацию.
Мне сейчас не очень хочется подробно расписывать что к чему. Приведу вариант настройки, из него все поймете сами.

Линия К-98Линия порта ВНастройка реле
K1 (2)B1 (20)ANT
K2 (3)B2 (21)ANT
K3 (4)B3 (22)ANT
K4 (5)B4 (23)ANT
K5 (6)COM (4)
PTT IN (T)B7 (10)SEQ
PTT IN (S)B7 COM (6)

Очень важно переключить джампер PORT B в самом Station Master в положение EXT, иначе попалите реле в K-98.

Настройки коммутации:


Для корректной работы со Station Master в автоматическом режиме необходимо (на Station Master включен режим Split и выбрана K-98 в качестве приемной антенны) необходимо переключить галлетник направлений приема на блоке питания K-98 в положение "S".

Вот такой вот хак.

RA6LBS
Link - Sun, 15 May 2011 11:46:15 GMT
Сегодня почитал про антенны нижних диаппазонов от RA6LBS, посмотрел схемки.
Знаете что? В принципе, три его RB2 с коммутатором K4/8 отлично вешаются на microHAM Station Master с настроенной виртуальной повороткой, так что для софта (логгеры с управлением повороткой) получается вообще все в шоколаде!
Но меня больше заинтересовал вариант с К-98. Я написал RA6LBS пиьмо по поводу "офицальной" возможности такого подключения. Ждем ответа.

Управляем повороткой с помощью microHAM Station Master под Mac OS X
Link - Wed, 11 May 2011 04:35:16 GMT
Продолжаем тему разработки полезняшек раскрывающих функции железок microHAM под Mac OS X. Ранее разработанный мной драйвер петли последовательных портов предоставляет для этого широкие возможности. :)
microHAM Station Master содержит в себе интерфейс поворотного устройства. Используя его убиваем кучу зайцев. Да не задача, он использует свой проприетарный протокол microHAM (который, напомню, мультиплексирует еще массу всего), так что напрямую основной массой софта, как обычно, не поддерживается.
Версия ПО для Windows эмулирует интерфес HyGain DCU-1. Пойдем под Mac OS X тем же путем. Разве что утилита опять консольная.

Еще один вялотекущий проект: автоматическое управление антенной ФАП
Link - Mon, 25 Apr 2011 05:03:14 GMT
Про магнитные антенны в сети можно прочитать хороших и плохих отзывов, все достаточно неоднозначно. Четко можно сказать следующее: они не работают на передачу, ловят кучу всякой "дряни", но в то же время прекрасно работают на низкочастотных диаппазонах имея размеры многократно меньше длинны волны.
Мне тоже захотелось попробовать такую штуку. Коммерческие образцы добротностью не отличаются, неудобны в настройке, а порой даже жестко заточены под конкретную полосу. Все это не добавляет энтузиазма. Но давайте посмотрим на советскую оборонную промышленность - за время "железного занавеса" было выпущена масса прекрасных решений на феритовых и рамочных антеннах. Первопроходец, ныне массово списываемый в войсках и изредка появляющийся у барыг - ФАП (ферритовая антенна приемная), которая шла на радиостанциях Р-140М и Р-161.

Антенна устанавливалась на крыше и использовалась для приема во время движения. На радиостанции Р-140М, поскольку антенна фактически была опцией, к ней прилагался вот такой пульт управления:

На станции Р-161 отдельного пульта уже не было, по этому этот пульт достаточно тяжело найти. Я вот уже три месяца как никак не найду (если кто может помочь - напишите).
Разрабатывая эту антенну инженеры удилили особое внимание широкому диаппазону приемных частот, антенна имеет достаточно слабые ферритовые стержни 200. Вся сила антенны в интегрированном ламповом двухкаскадном усилителе.
Дальнейшим продолжением ФАП стала антенна АЗП (антенна зенитного приёма), с большим диаппазоном настроки резонанса и усилителем на полевых транзисторах, применяется на "Арбалетах" (Р-165).

Кроме того, отечественная промышленность выпускала и другие няшечки, например "Фартук" (15Э1213) и "Битта" (15Э1037). Вот бы "Битту" достать, но ее вообще днем с огнем не сыскать...



И так, имеем ФАП (пульта пока нет) и современную радиостанцию. В отличие от "классической" инсталляции ФАП на кузове ЗИЛа у нас расстояние от радиостанции до антенны приличное. С таким расстоянием, если пульт ФАП тащить домой, напряжение накала упадет на столько, что настанет хана всем лампам в усилителе. Каждый решает эту проблему по своему. Например, RU6LM сделал дополнительный повышающий трансформатор. Но это не наш способ. Наш способ - поставить блок питания как можно ближе к антенне.
Пульт управления ФАП имеет дополнительных вход дистанционного управления, через которых радиостанция может переключать настройки антенны. Вход этот представляет собой 10 линий управления "Волна №..", идущий на матрицу коммутации "Память", на которой с помощью гвоздиков выставляются настройки для каждой из программ. Глядя на схему пульта несложно догадаться, что хитрым образом воткнув эти гвоздики можно добиться трансляции входящего двоичного сигнала в выходящий 1:1 (антенна имеет 2 линии для настройки индуктивности и 8 для настройки емкости LC-контура). Таким образом можно реализовать управление из шэка, разместив пульт около антенны. В случае, если пульт найти не удаться, это будет единственный доступный способ управления антенной, прийдется лишь изготовить блок притания.
Но Я был бы не Я, если бы на этом все закончилось. Я периодически забываю что-либо переключить - антенный переключатель или еще что-либо. Согласитесь, было бы совсем не удобно вращая энкодер частоты на радиостанции еще задумываться о переключении тумболеров управления антенной. Извращение какое-то. Текущая концепция выглядит так:

Помните, что я писал о причинах покупки microHAM microKEYER и Station Master? Эти интерфейсы могут совершенно прозрачно для софта считывать со станции частоту и раздовать ее (или ее производные) разным потребителям. На microKEYER для такой "раздачи" помимо проприетарного интерфейса для линка с Station Master есть еще стантартный ICOM-овский CI-V. CI-V - это интерфейс с открытым коллектором и TTL-уровнями, фактически общая шина, так что потребителей может быть несколько. Прототип, а скорее всего и конечное решение для удаленного автоматического управления делаем на Arduino Mega, попутно прицепив к нему Mega Sensor Shield для того, чтобы подключать все через удобные разъемы, а также DFRobot LCD Keypad Shield для вывода информации и ручной подстройки / настройки.
Схему согласования CI-V со входами AVR по хорошему нужно сделать с буферными регистрами 7407, как вот на этой схеме, а пока на первое время берем вариант из этой схемы:

Это хозяйство я собирал прямо на разъеме, по этому получилось следущее:

Для управления антенной я планирую использовать оптронную развязку с GIO на базе MCP23017, это позволит избежать тонны проводов к Arduino, а так же без проблем подключить оптроны без использования дополнительных ключей: у AVR2560, в отличие от MCP23017 весьма невысокая нагрузочная способность. Выводом я займусь немного попозже, хотя чипы уже давно приехали.
Прошивку я написал еще зимой, сейчас только исправляю ошибки да дорабатываю юзабилити. Изначально я думал реализовать все с помощью простой матрицы, да не тут-то было. Из расчета хотя бы 4 байт для каждой точки получаем уже 4 килобайта для всей матрицы (которых у нас попросту нет в EPROМ) и непозволительное время поиска. Хорошо, что формулу Томпсона пока никто не отменил, по этому пришлось реализовывать математическую модель. :)
С значениями емкостей все понятно из схемы - обычная двоичная набивка, даже очень веселая: 0-255 пФ. А вот с индуктивностями пришлось помучится. В схеме они не расписаны, на самих катушках на антенне для отечественного применения - тоже. Лишь на каком-то из польских форумов нашел снимки открытой антенны экспортного варианта, на которой были расписаны индуктивности. Там же были найдены эталонные настроечные таблицы. Вычисления в Excel показали, что разработчики также замечательно учли паразитную емкость цепи, о которой нигде не слово. По моим расчетам она составляет порядка 68 пФ. Возможно практика это значение скорректирует.
На выходных найдя свободное время приступил к натурным испытаниям без антенны.
С трудом нашел дефект в программной реализации CI-V у себя - "меньше" вместо "меньше или равно", из-за этого частота не декодировалась. Так же натурные испытания показали, что нужно слегка подкорректировать лимиты диаппазонов. Еще пару вещей пришлось доделать по юзабилити.
В общем, пока имеем вот такой вот прототип:


uH Router Serial Port Redirector for Mac OS X
Link - Fri, 22 Apr 2011 04:32:20 GMT
Фуф... Ну, вроде как все. Сделал консольную (GUI-ческую пока нет желания делать) утилитку, которая используя мой драйвер петлевого последовательного порта перекидывает все данные (CAT + PTT) на uH Router.

Картинка теперь выглядит так:


Стрелочка напрямую между драйвером LoopbackDriver и утилитой PushToPipe означает то, что утилита умеет "мапить" нужные модемные сигналы (DSR, RTS, RI) самостоятельно.

Нереально волшебная задница Mac OS X
Link - Wed, 20 Apr 2011 19:23:52 GMT

Меня умиляют решения с асинхронным вводом-выводом в современных операционных системах. Он вроде как есть, но его вроде как нет.
Задачка: делаю редиректор с последовательного порта в UNIX pipe. Нужно переложить данные из порта в один pipe, "модемные" биты - во второй, а из третьего - читать и писать эти данные в порт. Задачка несложная, даже весьма простая, вроде как.
Начинаем изучать проблемную область... Первое, что видим - "модемные" биты нельзя опрашивать асинхронно, за их опрос отвечает соответствующий системный вызов ioctl. Время опроса нам не столь критично, будем дролбиться каждые 100 миллисекунд. Получаем ситуацию, что нам нужно ожидать изменения пары дескрипторов (порт и входящий pipe) и некоторого таймаута. Для данного действа в POSIX у нас есть целых три способа - poll, select и kqueue, унаследованный от BSD.
select явно попахивает математиками из комитета по стандартизации C++ - поганее способа придумать нельзя было - каждый раз для метода нужно прогружать новую таблицу дескрипторов, чтобы после вызова получить в нем из всего списка только те, по которым нужно произвести изменения, Не забываем, что нам эту дурацкую операцию нужно проводить каждые 100 миллисекунд. Получается, что на создание этого списка и передачу его в kernel space тратиться больше ресурсов чем на всю последующую работу. Параметр таймаута, кстати, тоже нужно каждый раз перезаписывать.
Ну вроде как на замену select-у есть станларный poll и замечательно продуманый kqueue. Но... по не понятной для меня причине Mac OS X и все ее производные не поддерживают работу kqueue с устройствами TTY! На его дескриптор попросту получаем EINVAL.
Хорошо, у меня в рукаве есть третий замечательный и весьма стандартный метод - poll. Ну и с ним мы наступаем на те же самые грабли. Получается, что замены весьма неэффективному select-у в таких задачах нет! Ну что же, прийдется смириться.

Posted via LiveJournal app for iPhone.


WMR968 и Linux
Link - Thu, 14 Apr 2011 15:09:45 GMT
Давно хотел обзавестись такой погодной станцией, чтоб можно было подключить ее к компьютеру, писать журнал и отдавать данные в APRS.
Соответственно, станция искалась с уже давно расковырянным протоколом и открытым ПО. Выбор пал на недорогую Oregon Scientific WMR968. У нас в стране цены на такие станции дикие, да и большая часть датчиков ретейлового набота мне не нужна (датчик осадков, флюгер, датчики с подзарядкой на солнечных батареях). Решил покупать потихоньку в Штатах в виде компонентов на замену.
Так в прошлом году к уже имевшимся двум дареным станциям появилась более-менее нормальная. Но реально заняться руки дошли только сейчас.
Станция имеет однонаправленный интерфейс RS232, со стороны компьютера только сигнал готовности к приему DTR. Станция с неохотой "сплевывает" закешированные на ней данные датчиков, а в дальнейшем транслирует только дельту, если происходят изменения.
Имея такие особенности, самая приспособленная к таким станциям программка - wx200d имеет два основных компонента - консольного клиента и демона, осуществляющего журналирование и предоставление данных из своего кэша по запросу клиенту. Все бы хорошо, если бы не синдром unix-овых лоботрясов: программа выгружает данные в нативном формате более старой станции WR200, а для поддержки более свежих станций в ней имеется транслятор сообщений в более скудный старый формат. Однако.
Так вот, встроенная поддержка WMR9x8 адекватностью не отличается - пишет в журнал только при наличии всех датчиков, а имеющийся у меня THC268 вообще не понимает. Пришлось патчить.
Патч тут. Натягивать на самую последнюю версию из CVS - 1.3.2.

My last 2 QSO
Date Station Locator Band Mode RST R RST S
2012-08-29 09:27 R3ABM RA4FBY LO06aa 40M LSB 59 59
2012-08-29 09:27 R3ABM RA4FBY LO06aa 40M LSB 59 59