Pull to refresh
152
0
Андрей Смирнов @smira

User

Send message
aptly работает только с пакетами, которые полностью скачены (иначе нет возможности поддерживать snapshot).

«Чтобы вытащить 5 пакетов из зеркала», можно сделать примерно так:

aptly repo create repo1
aptly mirror create -architectures="i386" -filter='pkg1 | pkg2 | pkg3' mirror1 ....
aptly mirror update mirror1
aptly repo import mirror1 repo1 'Name'


aptly выкачает только пакеты, которые удовлетворяют условиям фильтра, полный синтаксис здесь.
Если сравнивать брокеры сообщений — они все примерно похожи на AMQP. Если смотреть на другие варианты очередей (beanstalkd, Kafka, и т.п.) — это другие решения с другими характеристиками. ØMQ — обмен сообщениями без брокера.
Лучше смотреть на картинку «Deferred в квадрате», и рассматривать Deferred2 как отдельный поток, который начинается выделением ресурса (т.е. к моменту прихода на уровень callback2_1 ресурс уже выделен).

У Deferred есть метод .addBoth, который добавляет один и тот же обработчик на оба слота (callback/errback) на одном уровне. Это модель try...finally, который и используется для гарантированного освобождения ресурса при любом исходе.
Мой комментарий относился ни к скорости создания нитей, ни к красоте кода.

В общем случае, чистый код в нитях (без другой модели программирования, например Actor в Erlang) крайне труден в поддержке/разработке из-за наличия тех или иных синхронизаций, число которых для получения приемлемой скорости растет.
Я не готов сравнить их. EventMachine — это «Twised на Ruby».

То есть на верхнем уровне это скорее различие языков и философий программирования, определяемых языком.

Вообще говоря Ruby MRI на сегодня медленнее Python.

Может, кто из пробовавших оба расскажет?
Дело было примерно так — автор Tornado пытался понять Twisted, писал в список рассылки, спрашивал. Но так и не понял и сделал Tornado. Видимо, такова его ниша (Tornado) и такое «упрощенное» решение имеет право на существование.

Без обид. Просто другой взгляд на вещи.

Поэтому я думаю сравнение технологий без определения критериев и конкретных метрик бесмысленно.
Не за что! Видео с конференции я, к сожалению, не могу найти.
Да, пока прогресса нет, к сожалению. Буду рад любому, кто подберет проект — помогу и советом, и делом.
Уточню: гораздо меньший битрейт за счет использования хорошего кодека, и возможность экспортировать записанные видео в родную Фотогаллерею айФона — где появляется возможность тримить видео и загружать его на РС.
А так вообще на джейлбрекнутых айФонах можно пользоваться намного лучшим API по захвату видео, соотв. FPS (кадров в секунду) там всегда будет лучше пока Apple нормальный API не откроет.
Гораздо меньший битрейт за счет использования хорошего кодека
Нет, речь как раз идет о видео, но для iPhone 2G & 3G
Там мелкие багфиксы в разных точках, где что-то ломалось. Ничего серьезного.
wiz, нет еще… Если интересно, могу кинуть код лично. Публиковать еще не готов пока ;)
Спасибо большое, даешь AMQP в массы!
Мне кажется, что обязательно надо об этом написать!
На самом деле это не такой маленький список. Для работы Qik нужна в телефоне качественная камера, а для live неплохой канал: WiFi/3G/Edge. Поэтому поддержать совершенно любой телефон смысла нет, но мы постоянно занимаемся расширением перечня моделей телефонов, на которых Qik работает.
C Qpid не все так просто. Java-версия умеет 0-8.
Мне трудно сказать, я не эксперт в Erlangе, знаю, что там замечательный внутренний messaging. Чаще всего рано или поздно придется интегрироваться с другими системами, написанными на чем-то еще. И вот тогда «прослойка» в виде AMQP-брокера может очень даже пригодится.

P.S. RabbitMQ (AMQP-брокер) как раз написан на Erlang.
Присоединяюсь, пробовал и его и Qpid. Qpid проще в процессе прототипирования (проще запустить и управлять), а в продакшне уже Rabbit!

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity