• Aptly — создание собственного репозитория
    0
    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 по-русски
    0
    Если сравнивать брокеры сообщений — они все примерно похожи на AMQP. Если смотреть на другие варианты очередей (beanstalkd, Kafka, и т.п.) — это другие решения с другими характеристиками. ØMQ — обмен сообщениями без брокера.
  • Deferred: все подробности
    0
    Лучше смотреть на картинку «Deferred в квадрате», и рассматривать Deferred2 как отдельный поток, который начинается выделением ресурса (т.е. к моменту прихода на уровень callback2_1 ресурс уже выделен).

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

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

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

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

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

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

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

    P.S. RabbitMQ (AMQP-брокер) как раз написан на Erlang.
  • AMQP по-русски
    0
    Присоединяюсь, пробовал и его и Qpid. Qpid проще в процессе прототипирования (проще запустить и управлять), а в продакшне уже Rabbit!
  • Memcached — стратегия кеширования
    +1
    Сергей, может быть Вам подойдет и Ваша система. Наверное, она работает.

    Просто аудитория Хабра состоит в том числе и из тех, кто еще еще только собирается написать свою систему кэширования. И было бы лучше, если бы они учились на более правильных примерах, чем Ваш. Чтобы они не набивали свои собственные шишки, а воспользовались уже готовыми решениями.

    Как использовать более «правильные» подходы к кэшированию? Я бы советовал взять, например, библиотеку Котерова. Или посмотреть продвинутые frameworkи кэширования, например, в рельсах. Может, кто еще из Хабровчан расскажет о хороших примерах, я доступных примеров больше не знаю, к сожалению.
  • FMSPy, релиз Alpha (0.1)
    +3
    Сам сервер однопотоковый, это сильно упрощает дизайн и облегчает производительность (event-driven). RTMP как таковой с трудом можно разделить на нормальную многопоточную обработку, в отдельный поток можно вынести независимую задачу (например, перекодирование видео). План состоит в создании автоматически (или полуавтоматически) кластеризуемого решения. Тогда на одном сервере запускаем столько FMSPy, сколько там ядер. Используем столько серверов, сколько нам нужно. Все это работает как единый организм, распределяя нагрузку внутри себя так, чтобы все сервера были загружены примерно одинаково.

    Так что нет, GIL не смущает.
  • Memcached — стратегия кеширования
    0
    Сергей, я не претендую на авторство в вопросе тэгирования. Скорее, это мы с Димой Котеровым почти независимо пришли. Я лишь хочу сказать, что надо пробовать что-то лучшее сегодня уже. Гораздо проще начинать с хорошего, когда оно уже опробовано кем-то и описано.

    Так что, даешь новую статью про улучшенную Вами же Вашу систему кэширования!
  • FMSPy, релиз Alpha (0.1)
    +2
    Если брать Wowza/FMS — все-таки есть уверенность, что нужно open-source решение, которое бы позволяло технологию вперед. У FMS/Wowza есть свои проблемы с надежностью и не всегда полной поддержкой.

    Если брать Red5/rtmpy/Milenia Grafter и другие open-source проекты: Red5 — тормозит и глючит (опыт реального использования под нагрузкой). С моей точки зрения это монстр, который может жить только в руках создателей. Rtmpy — на начальном этапе развития, у FMSPy есть общий код с ним, близкие проекты. Но путь Rtmpy меня не устраивает. Milenia как-то тихо загибается в непонятном пути развития.

    RTMP — очень полезная технология, которая может иметь множество применений. Нужно только ее развитие. FMSPy — это не только сервер RTMP, это еще и протокол RTMP, который можно использовать в любом Twisted-приложении.
  • FMSPy, релиз Alpha (0.1)
    0
    Для разработчиков приложений для FMSPy (то есть по API FMSPy) или для разработчиков самого FMSPy?

    Из неопубликованного есть автоматически сгененированная документация по коду, ее можно и самому легко собрать — git clone, make docs
  • FMSPy, релиз Alpha (0.1)
    +1
    1 (одна) шт. :)
  • FMSPy, релиз Alpha (0.1)
    +1
    Ну, наверное, это не совсем то, что должно входить в ядро FMSPy. Это типичная задача для приложения к FMSPy: мы получаем по RTMP потоковый звук от пользователя, на сервере проделываем микширование и выдаем (публикуем) в качестве стрима. В FMSPy должны быть все возможности для этого: захват живого стрима, публикация стрима. Микширование и кодирование/декодирование потока, наверное, будет выходить за рамки FMSPy, но для этого стоить использовать готовые возможности Python, например, интерфейс с GStreamer.
  • FMSPy, релиз Alpha (0.1)
    0
    Тестируйте, пожалуйста, устанавливайте, пробуйте, ищите баги и т.п.! Все, что получится, пишите в трекер на fmspy.org/ в виде тикетов. (Чтобы создать тикет, надо зарегистрироваться). Спасибо!
  • FMSPy, релиз Alpha (0.1)
    0
    Честно скажу, не было. Если есть идеи, как это реализовать, я был бы рад совместно работать над интеграцией!
  • Memcached — стратегия кеширования
    0
    Спасибо!

    Если я правильно понял автора, то, что он предлагает является вырожденным случаем тэгирования кэшей. При этом некоторые утверждения в статье, как писали уже выше в комментариях, являются как минимум спорными.

    Эффективность описанной системы кэширования должна быть низкой, если ничего не путаю по тексту, то при изменении любой таблицы сбрасываются все кэши, затрагивающие эту таблицу. Такой подход не может работать на реальном проекте. Изменение таблицы коментов на Хабре не должно приводить сбросу всех кэшей комментариев ко всем статьям. В крайнем случае — только к той статье, к которой был добавлен/удален/изменен комментарий.

    Как раз задачи минимизации сброса кэшей является актуальной, кэши должны сбрасываться редко (они должны быть так устроены). Опять-таки, если я не путаюсь в мыслях автора, он предлагает перейти от сброса «всех вообще кэшей» при любом изменении к сбросу «всех кэшей, связанных с таблицей, при изменении таблицы». Ммм… это каменный век кэширования! Давайте двигаться вперед! :)
  • FMSPy, релиз Alpha (0.1)
    +1
    Пока не допишем, ясно не будет. Целью является сопоставимая или лучшая производительность. Хотя непосредственно оптимизация в планах отложена на чуть более поздний этап оп времени.

    Nerezus, вы можете помочь! Если не непосредственно участием в разработке, то, например, организацией тестирования производительности. Мы (все вместе) смогли бы несомненно сделать его лучше.

  • FMSPy, релиз Alpha (0.1)
    +5
    Я не думаю, что разработка может быть быстрее на Java или каком-то еще языке программирования. Современные framework'и дают примерно равное время разработки (объем усилий).

    Это делается на Python, потому что для меня так удобнее. Я не вижу недостатков такого решения (или знаю как такие недостатки обойти).
  • Deferred для Javascript (Prototype)
    0
    Ой как много… Но без Deferred нужно еще больше программистов!
  • Deferred для Javascript (Prototype)
    0
    Взаимно! :)
  • Deferred: все подробности
    0
    1. Таймаут нужен там, где он может произойти, ну, например, вызов connect(). Если он завершится ошибкой, надо в цепочку Deferred запустить Failure, т.е. обычное исключение. Таймаут не отличается от разрыва соединения и т.п. Twisted это умеет.
    2. Не несет существенного, она очень-очень простая. Полторы страницы кода (Python). Научиться ей пользоваться и думать в её терминах сложнее, но реализация простая и эффективная.
  • Deferred: все подробности
    0
    И еще был чудесный баг, twistd не запускал процесс в фоне с --reactor=kqueue. Помогал ключик '-n' и уход в демона внешними средствами.
  • Deferred: все подробности
    0
    Там с kqueue надо было патчить порт py-kqueue, после этого счастье ;) А еще был баг в самом Twisted, но они это пофиксили в новых версиях.
  • Deferred: все подробности
    0
    По умолчанию Twisted биндится на все интерфейсы, возможно это у него не получается, и надо ему сказать выбирать конкретный адрес (интерфейс). Ну и на всякий случай не-рутовые приложения не могут получить порт ниже 1024.
  • Deferred: все подробности
    0
    Ох, не силён я в терминологиях хостинговых )

    По сути, twisted-приложение — это обычное питоновское приложение. Если есть python, есть возможность запускать процессы «в фоне» (есть шелл), есть возможность установить питоновский пакет (twisted), есть возможность забиндиться на порт и т.п., то приложение будет работать. Для этого нужен выделенный сервер или виртуальный выделенный сервер (т.е. наличие своего IP, шелла и т.п.). Рутовый доступ как таковой не нужен, если есть Python, все пакеты можно установить и в свой домашний каталог.
  • Deferred: все подробности
    0
    Насчет Java ничего не знаю, к сожалению… Twisted, насколько я знаю, близок к тому, чтобы работать под Jython, т.е. в каком-то плане может быть доступно.

    Самая большая проблема для статически типизированных языков — построение цепочки callbackов, на C++ в реализации самая большая проблема именно с этим, там жуткие шаблоны ;)