Веб-разработка → Realtime xRTML — новый html-подобный язык разметки

Всем привет!
Речь пойдет о новом запатентованном HTML-подобном языке разметки — xRTML, который позволяет редактировать функционал сайта в реальном времени без использования Ajax.
Разработчиками xRTML является часть португальской команды IBT (Internet Business Technologies), которые стремясь создать новый и доступный язык разметки, позволяющий быстро вносить изменения на сайт в реальном времени, придумали xRTML.
Главными ключевыми особенностями xRTML являются его простота в изучении, необходимость только одной строчки кода, плагины для систем блогов, такой как WordPress, API для серверных языков, кросс-браузерность и кросс-платформенность
— команда xRTML
Работа со звуком → Аудио микшер из двух и более звуковых карт на realtime Linux и Reaper из песочницы
Когда играешь в группе, надо где-то репетировать. Попробуем дома собрать свой микшер с эффектами из того, что есть под рукой. А под рукой у меня есть 2-х ядерный компьютер с встроенной и 2-мя дополнительными аудиокартами, ESI Juli@ и C-Media CM8738. Итого 6 каналов на запись.
Если достаточно 2-х каналов, то можно дальше не читать, потому как 2 канала можно смикшировать через Reaper под Windows с asio4all (или родными драйверами), будет играть без проблем. Вся сложность начинается, когда хочется из 3-х карточек сделать одну виртуальную и многоканальную. Через asio4all запись одновременно 6-ти каналов на приемлемом уровне качества (даже для репетиций) не получилась (из-за разного clock source на карточках, а также из-за редких подтормаживаний), поэтому и пришлось идти таким нелёгким путём.
Если достаточно 2-х каналов, то можно дальше не читать, потому как 2 канала можно смикшировать через Reaper под Windows с asio4all (или родными драйверами), будет играть без проблем. Вся сложность начинается, когда хочется из 3-х карточек сделать одну виртуальную и многоканальную. Через asio4all запись одновременно 6-ти каналов на приемлемом уровне качества (даже для репетиций) не получилась (из-за разного clock source на карточках, а также из-за редких подтормаживаний), поэтому и пришлось идти таким нелёгким путём.
Обработка изображений → Папоротники как метод распознавания образов
Доброго времени суток! Как известно, одной из важных задач, решаемых обработкой изображений (помимо сброса пары кг и укрывания дефектов кожи на аватарках), является поиск и распознавание нужных нам объектов на сцене. Но этот процесс весьма сложный и ресурсоемкий, что делает его неприменимым в системах реального времени. Сегодня мы и поговорим, нельзя ли каким-то образом решить эту проблему и ускорить процесс поиска нужного объекта на сцене, с минимальными потерями в точности (а может, и без них вовсе). И вообще, причем тут папоротники?
PS
Традиционно много картинок.
Блог компании Intel → Особенности работы кэша применительно к realtime на x86
Небольшое лирическое отступление. Системы реального времени — один из наименее известных двигателей компьютерного прогресса. Например, первый портативный компьютер был создан благодаря им. Сейчас почему-то считается, что первым серийным портативным компьютером был Osborn. На самом деле устройство на картинке выше было создано в Сименсе как cредство управления и программирования промышленной автоматизации за два года до Osborn. Переносные компьютеры этого семейства (Siemens Simatic) выпускаются и сейчас, хотя, конечно, железо много раз менялось.
Но перейдем к делу. В этом топике я подробнее остановлюсь на одном из факторов, который мешает предсказуемости времени выполнения realtime кода. Под катом будет не длинный, но нудноватый текст.
Блог компании Intel → Worst case execution time на x86
В прошлом посте я описал, как и зачем измеряется interrupt latency на платформе Atom.
Сегодня расскажу о том, почему один и тот же код с одними и теми же входными данными может исполняться разное время. Для некоторых realtime приложений это очень нежелательный эффект, с которым приходится бороться.
Сегодня расскажу о том, почему один и тот же код с одними и теми же входными данными может исполняться разное время. Для некоторых realtime приложений это очень нежелательный эффект, с которым приходится бороться.
Блог компании Intel → Вопросы использования Intel Atom для embedded realtime задач
После того, как архитектура Atom проявила себя в нетбуках, некоторые компании стали использовать Atom для Embedded Realtime применений. Делают промышленные контроллеры, гоняют на них PLC код.
Те же чипы, что и в нетбуке обычно на заводах не используют. Есть специальный платформы. Сначала был Crown Beach, сейчас начинает использоваться в дизайнах Queens Bay. Для IVI (автомобильный компьютер) есть своя платформа.
Естественно, удовлетворение realtime требований — необходимое условие. Об этом подробнее под катом.
Те же чипы, что и в нетбуке обычно на заводах не используют. Есть специальный платформы. Сначала был Crown Beach, сейчас начинает использоваться в дизайнах Queens Bay. Для IVI (автомобильный компьютер) есть своя платформа.
Естественно, удовлетворение realtime требований — необходимое условие. Об этом подробнее под катом.
Веб-разработка → «Прямой эфир» для общения c посетителями вашего сайта
Сегодня я хочу представить и, как водится, немного «покопаться в моторе» первой версии продукта Прямой эфир, работающей на платформе РуТвит с применением Realplexor-а. Это виджет, который вебмастер может за 1 минуту установить на свой сайт, чтобы устроить микроблоггинг-общение с аудиторией в режиме реального времени.
С помощью «Прямого эфира» аудитория сайта общается между собой в реальном времени — «прямо сейчас», находясь в отдельной «чат-комнате», привязанной к вашему сайту. Виджет можно использовать для «прямого диалога» сразу со многими пользователями: например, для приема багов или фич-реквестов. Если пользователь, с которым вы общались, всё еще на сайте, вы увидите его присутствие: около его имени будет зеленый кружочек.
Для начала общения посетителю сайта нет необходимости проходить процедуру регистрации. Авторизация производится по OpenID. Т.е. ему достаточно иметь аккаунт на Яндексе, Google, LiveJournal и т.д., чтобы начать писать сообщения; не требуется даже e-mail.
Высокая производительность → Realplexor: производительный Comet-сервер с API для PHP и Javascript (realtime)
Dklab Realplexor — это Comet-сервер, позволяющий держать одновремено сотни тысяч долгоживущих открытых HTTP-соединений с браузерами пользователей. Javascript-код, запущенный в браузере, подписывается на один или несколько каналов Realplexor-а и вешает обработчик на поступление данных. Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени и с минимальной нагрузкой для сервера. Хотя идейным вдохновителем Realplexor-а был предыдущий проект, dklab_multiplexor, код Realplexor-а не имеет с ним практически ничего общего. Поэтому я и решил сменить название. Несопоставимы также возможности продуктов (см. ниже), да и размер кода увеличился в 7 раз.
Realtime-направление сейчас довольно активно развивается на Западе, и в нем особенно выделяется продукт Tornado — событийно-ориентированный веб-сервер на языке Python. Правда, Tornado — это не столько Comet-сервер, сколько инструмент, с помощью которого можно запрограммировать «в том числе» и Comet-сервер. Ключевые слова: Comet, Push Server, Long polling, Javascript, XMLHttpRequest.
Главные преимущества Realplexor-а:
- простота использования: наличие API для Javascript, API для PHP (в будущем — и для других языков);
- простота конфигурирования;
- широкий функционал (либо отстутствующий, либо недоступный напрямую в аналогах).
Лучше один раз увидеть...
Я сделал отдельную онлайн-песочницу, чтобы продемонстрировать функционал нового Realplexor-а и то, для чего вообще нужны Comet-серверы (кстати, это физически тот же самый демон Realplexor-а, что использует мой новый стартап РуТвит). Песочница реализует что-то типа многоканального чата: зайдя, вы получите как будто бы 2 независимых «браузера», запущенных на разных компьютерах.
- Верхний «браузер» отображает каналы — в них моментально появляются новые сообщения, как только кто-то их туда отправляет на стороне сервера. Конечно же, эту страницу могут просматривать одновременно сотни тысяч пользователей, и они все будут видеть одно и то же (реализовано с использованием Realplexor Javascript API). Можно «на лету» добавлять новые каналы (подписка) или скрывать уже имеющиеся (отписка).
- Нижний браузер содержит формы, позволяющие добавлять сообщение в произвольный канал, указав его имя. Форма AJAX-ом отправляется на сервер, и уже там PHP-скрипт записывает в Realplexor полученный текст через PHP API. (И да, так можно чатиться.)
Песочница демонстрирует следующие функции Realplexor-а:
Linux для всех → Я использую Brain Fuck Scheduler!

pic related
Кон Коливаc (автор знаменитых когда-то ck ядер) выпустил свой шедулер для десктопных систем под управлением linux. При этом он руководствовался не супер-честностью и мифической расширяемостью, а производительностью своего рабочего компьютера.
Обыгранная на картинке ситуация — беда многих опенсорсных программистов — они пишут фреймворки и общие-системы-всего и не желают исправлять очевидные недостатки, просто потому, что наличие этих недостатков объясняется стройностью их системы. Линус — не исключение.
Надеюсь, когда-нибудь BFS включат в ядро и его можно будет включить просто из menuconfig'a.
PS А полноэкранное видео на youtube действительно больше не тормозит! Посмотрел для теста несколько HQ трейлеров.
ck.kolivas.org/patches/bfs/bfs-faq.txt
ck.kolivas.org/patches/bfs/
Убунтариум → RT-ядро в Убунту. Быстро и без головной боли.
Недавно прочитал статью небезызвестного в кругах «дебианщиков» и «убунтушников»
блогера virens'а про realtime ядро. Оригинал тут.
Меня данная тема заинтересовала, так как проблемы плохой отзывчивости системы при больших нагрузках свойственны и моему ноутбуку.
блогера virens'а про realtime ядро. Оригинал тут.
Меня данная тема заинтересовала, так как проблемы плохой отзывчивости системы при больших нагрузках свойственны и моему ноутбуку.