Так сложилось, что в Qt4 Embedded, которую мы используем на нашем приборе Беркут-ММТ, нет поддержки таких устройств ввода, как энкодер. Т.е. если прицепить к прибору мышь — координаты при перемещении обрабатываться будут, а вот колесо прокрутки — нет. Потому что драйвер linuxinput не обрабатывает события с типом REL_WHEEL, которое генерит энкодер, а только REL_X и REL_Y, которые отвечают за изменение координат.

Кому интересно как эту проблему решить — добро пожаловать под кат.

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

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Среды разработки С++ для Ubuntu

При переходе на Ubuntu первой задачей был поиск удобной среды разработки.
Перед выбором выступили такие кандидаты: Code::Blocks, Netbeans, Eclipse, Anjuta.
Продолжение под катом.

Под мерой производительности UI будем понимать количество откликов на действия пользователя в единицу времени. А под откликом — запрашиваемую пользователем реакцию приложения.

Малым временем отклика можно объяснить ряд предпочтений пользователя:

1. Предпочтение аналоговых интерфейсов цифровым (когада возникает задержка на обработке цифрового ввода);
2. На заре Windows, — предпочтения пользователей работать с DOS программами в «текстовом режиме», а с не GUI аналогами в Windows (время отклика в текстовом режиме тогда было заметно меньше на сходной платформе);
3. Предпочтение реальных игровых консолей их эмуляторам (эмуляторы часто имеют время отклика отличное от времени отклика оригинальных консолей);
4. Предпочтение пользователей iOS и Android относительно WinCE и Symbian (среди прочего, например в iOS ставилась цель быстрого отклика и поддержки 60 FPS, Android хотя и не ставил таких целей был заметно отзывчивее WinCE и Symbian);
5. В автомобилях — неоднозначное отношение пользователей к автоматическим коробками передач, электронной педали газа и некоторым другим системам вносящим задержку между управляющим воздействием и реакцией на него (это относится к наименее продвинутым версиям этих решений).

Большое время отклика является по сути «обратной связью с запаздыванием», про которую более подробно можно прочитать тут: «Обратная связь с запаздыванием в кране с горячей водой, марсоходе и демографической пирамиде».

Время от времени на форумах рунета в ветке Qt появляются вопросы связанные с программированием сетевых приложений. Одна из проблем которая терзает этих людей, — это подход к организации сервера. Обычно перечисляют три подхода:

• однопоточный асинхронный;
• многопоточный, создавать по потоку на соединение;
• многопоточный, с пулом потоков на QThreadPool и QRunnable.

Когда говоришь про фиксированное количество рабочих потоков со своим циклом обработки событий, то просят привести пример. Дальше будет приведен пример сервера с пулом потоков, каждый из которых имеет свой цикл обработки событий.

Стандарт WiFi 802.11n использует механизм агрегации кадров для уменьшения накладных расходов при передаче данных.
Для этого несколько кадров объединяются в один. При этом маркер разделителя кадров передается вместе с данными.
Это позволяет сформировать данные, которые при прохождении через WiFi устройство будут интерпретированы им как отдельные кадры.

То есть имея контроль над потоком данных передаваемых от сервера клиенту (например при загрузке файла с сервера атакующего) или от клиента к серверу, можно генерировать произвольные пакеты на всех уровнях OSI:

• Пакет с любыми заголовками RadioTap: Beacon, Probe Request/Respone, Deauthentication
• L2 уровень: указать любой MAC адрес в заголовках пакета, можно производить ARP спуфинг
• L3/L4 уровень: скрафтить любой TCP/UDP/ICMP пакет с любыми заголовками IP
• и так далее

Уязвимости подвержены только открытые сети стандарта 802.11n.

Привет хабр!

Появилось таки некоторое количество времени, и я решил написать сий пост, идея которого возникла уже давно.
Связан он будет будет с такой, казалось бы, простой вещью, как URI, детальному рассмотрению которой в рунете уделяется как-то мало внимания.

"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Устройство для снимка экрана на первых компьютерах (Command-Shift-3)

Если вы когда-либо делали хелп или мануал для своего приложения, наверняка вы отметили, как неожиданно много времени и сил занимает создание скриншотов.

Ведь кажется, что скриншот — это “секунда работы, Alt+PrintScreen и Ctrl+V!”. Некоторые клиенты удивляются, когда слышат, что скриншот в мануале может стоить и $2 и даже $5.

В этой статье я расскажу, как правильно делать скриншоты, почему это не просто “два клика” и какие подводные камни встречаются на пути неопытного скриншотера. Рассматривайте ее как чеклист или список практических советов для тех, кто документирует ПО. Надеюсь, это поможет вам избежать разочарований и порадовать юзеров красочными понятными картинками.

После того, как я воплотил свою давнишнюю мечту и все-таки (хотя и с опозданием почти на 30 лет) построил Радио 86РК, некоторое время мне казалось, что на этой части моей истории поставлена вполне достойная точка.

Тем не менее, обнаружилось, что болезнь до конца не вылечена, и она вернулась еще более острым рецидивом. Наверное, сказались как неожиданно успешный опыт постройки 86РК, так и то, что у меня в ходе данного процесса образовалось довольно большое количество весьма притягательно выглядящих инструментов, приборов и деталей, которым очень хотелось найти применение.
В конце концов ломка стала нестерпимой, и мне пришлось снова взяться за паяльник, а также вспомнить некоторые другие навыки из прошлого. Что из этого получилось, можно увидеть вместе с некоторым количеством картинок и очень (повторяю – ОЧЕНЬ) большим количеством букв (и даже не букв, а страниц) дальше…

В уже далеком 1986 году у меня появилась мечта. Вернее, МЕЧТА – построить свою собственную микро-ЭВМ «Радио-86РК», схема которой была опубликована в журнале «Радио» (и который уже неоднократно упоминался на Хабре, например, здесь — habrahabr.ru/post/172405 ).

Животные – это платформы с очень ограниченной памятью, вычислительными способностями и возможностями модификаций. Разработчикам энимал-сцены приходится выдавать практически гениальные низкоуровневые алгоритмы. Правда, большое количество хардкода вызывает характерные проблемы с отсутствием проверки в экзотических условиях. Та же фильтрация входных данных делается очень и очень криво.


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

Не знаю, кто писал большую часть птиц, но я хочу обратить внимание на особенность, позволяющую провести инъекцию произвольного яйца в гнездо. Дело в том, что птица проверяет только расположение и количество яиц, но не их хэши. В 20% случаев кукушка, эксплуатирующая этот баг, может внести яйцо с сохранением контрольной суммы, чего вполне достаточно для повышения прав в гнезде.

Но пойдём далее. Я не знаю, кто разрабатывал архитектуру ящериц, но они бегают в одном процессе, а дышат в другом. При этом платформа не поддерживает многозадачность, поэтому костыль с максимальной длиной бега в 4-6 секунд просто эпичен.

Думаю многие знают, как работает CGI взаимодействие между клиентом и сервером: клиент получает от сервера и отдает серверу данные через стандартные stdin и stdout. Многие наверное даже сами писали CGI клиентов, ведь по сути — любой скрипт для веб-сервера это и есть CGI-клиент.
А многие ли задавались вопросом, как именно происходит эта «магия»? Каким образом стандартные функции для ввода/вывода вместо экрана взаимодействуют с сервером?

Результаты поиска ответа в сети меня не удовлетворили и я решил сам написать простейший CGI сервер, который сможет:

• Запускать дочерний процес — CGI скрипт
• Передавать скрипту переменные окружения и переменные командной строки
• Принимать от скрипта ответ
• Завершаться, когда завершится процесс клиента

Кроме этого, мне хотелось, чтобы клиент и сервер компилировались как в Windows, так и в Linux.

В комментариях к моей прошлой статье о способах защиты от неправильного подключения полярности источника питания меня неоднократно корили за то, что не упомянул способ защиты с использованием самовосстанавливающегося предохранителя. Чтобы исправить эту несправедливость поначалу хотел просто добавить в статью дополнительную схему защиты и короткое к ней пояснение. Однако решил, что тема самовосстанавливающихся предохранителей заслуживает отдельной публикации. Дело в том, что устоявшееся их название не слишком отражает суть вещей, а копаться в даташитах и разбираться в принципе работы при применении таких “элементарных” компонентов, как предохранитель, часто начинают уже после того, как начала глючить первая партия плат. Хорошо если не серийная. Итак, под катом вас ждёт попытка разобраться, что же это за зверь такой PolySwitch, оригинальное название, кстати, лучше отражает суть прибора, и понять с чем его едят, как и в каких случаях имеет смысл его использовать.

При проектировании промышленных приборов, к которым предъявляются повышенные требования по надёжности, я не раз сталкивался с проблемой защиты устройства от неправильной полярности подключения питания. Даже опытные монтажники порой умудряются перепутать плюс с минусом. Наверно ещё более остро подобные проблемы стоят в ходе экспериментов начинающих электронщиков. В данной статье рассмотрим простейшие решения проблемы — как традиционные так и редко применяемые на практике методы защиты.

В один прекрасный день захотелось самому себе дома делать эспрессо. Кофе играет важную роль в поддержании моей работоспособности. Речь идет скорее о вкусе напитка и привычке попивать кофе во время размышлений, чем о волшебно-бодрящем действии кофеина. Долгое время я варил кофе в турке и горя не знал. Ну как не знал. Не знал, пока не пришел черед действительно сложного и напряженного проекта. Сразу выяснилось — одной чашки маловато для поддержания достаточного уровня производительности. Душа требовала около трех порций в день.

Вот тут-то и начались сложности. Ничем типа «фууу растворимый кофе» я никогда не болел. Периоды этого нелюбимого многими суррогата и натурального кофе совершенно безболезненно чередовались в моей жизни ранее, но вечно продолжаться так не могло. Оказалось, что если пить растворимый кофе по несколько чашек в день, от него реально начинает тошнить. С заварным дела обстояли не лучше…

Всем доброго дня!

После прочтения нескольких статей на хабре о пластиковых картах, POS терминалах и сопутствующих вещах, мне показалось, что эта тема довольно интересна сообществу. В данной небольшой публикации я хочу окончательно разобрать тему ввода PIN–кода на POS терминалах и ответить, наконец, в меру своих знаний, на вопрос: почему же в одних случаях требуется ввод PIN, а в других — нет?

У хорошего интерфейса пользователя высокая конверсия и его просто использовать. То есть, он хорош и для бизнеса, и для использующих его людей. Вот список опробованных нами идей.

1 Один столбец вместо нескольких

Один столбец точнее отражает то, что вы хотите донести. Пользователи проходят сверху вниз по более предсказуемому пути. В дизайне с несколькими колонками есть риск отвлечения пользователя от основной задачи страницы.

[Вид старого города с высоты полета квадрокоптера]

Немного о себе: Работал в Санкт-Петербурге в Политехническом университете. Преподавал компьютерные сети, в основном, в рамках сетевой академии Cisco, имею статусы CCNA R&S, CCNA Security, CCNP R&S, так же являюсь Instructor Trainer’ом для соответствующих курсов.