Появилась задача написать веб интерфейс управления устройством. Управлять устройством будет Raspberry Pi. Логика управления — python, соответственно и интерфейс хотелось бы python. Хочу поделится своим опытом.

• 1. lighttpd mod_cgi и простой скрипт
• 2. web.py на порту 8080
• 3. WCGI интерфейс
• 4. Простой сервер WSGI
• 5. WSGI с использованием wsgiref
• 6. WSGI c помощью flup
• 7. web.py приложение с использованием flup
• 8. Немного особенностей

В предыдущей статье мы рассмотрели терминологию и математическую основу расчетов отказоустойчивости различных систем и выяснили, что на практике, когда речь идет об оценках MTTF (Mean Time To Failure — среднего времени до отказа) и других характеристик надежности, в большинстве случаев предполагается, что отказы подчиняются пуассоновской модели. Соответственно, их вероятностное описание основано на экспоненциальном распределении вероятностей.

Этот материал будет посвящен практическим аспектам применения этой модели, причем стоит сразу оговориться, что он широко используется, как в электронике, так и в самых разных областях: например, при оценке рисков в авиационной и атомной отрасли, прогнозирования в автопроме, оценке надежности облачных сервисов в Интернете и т.п. Общим предположением, повторюсь, является гипотеза о постоянстве интенсивности отказов λ, которая, как мы увидели из предыдущей статьи, обратно пропорциональна среднему времени безотказной работы MTTF=1/λ.

Итак, давайте для начала рассмотрим совсем простой пример: устройство, состоящее из двух элементов, для каждого из которых известны интенсивности отказов λ₁ и λ₂. Отказ любого из элементов приводит к отказу устройства в целом. Например, компьютер (условно) можно представить, как систему, состоящую из процессора и материнской платы. Пусть для них среднее время до отказа (MTTF) равны 2 и 3 годам (соответственно, λ₁=1/2 года^-1 и λ₂=1/3 года^-1). Какова будет оценка MTTF для компьютера, в целом? И какова вероятность отказа компьютера через 1 год после начала эксплуатации?

Поддавшись общей волне энтузиазма относительно систем «Умный дом», а также имея профильное образование инженера АСУ ТП, с удовольствием занимаюсь данной темой в виде хобби. В этой статье поделюсь с вами своим опытом реверс-инжиниринга популярного модуля ESP8266.

Содержание

1. Введение
2. Архитектура ESP8266
   
   • Карта памяти (адресного пространства)
   • Формат прошивки
   • Процесс запуска
3. Инструменты
4. Загрузка прошивки для исследования
   
   • ELF
   • Системная прошивка модуля
   • Пользовательская прошивка
5. Ассемблер Xtensa
   
   • Регистры
   • Базовые операторы
   • Функции
   • Условные переходы
6. Заключение
7. Ссылки

На форумах периодически возникают желающие слепить из arduino starter kit свою СКУД для машины, офиса. По схождению звёзд и при поддержке вдохновения, черпаемого из новостей о Free and open-source software (FOSS), именно этим мы решили заняться в свободное от учёбы время. Описание промежуточного результата работы оформили для подачи заявки на публикацию в почти небезызвестный журнал. Окромя воды и кратких определений составных частей, в нём собрано описание всего необходимого для написания, успешной компиляции и прошивания скетча, управляющего моделью. Заявленная цель работы – создание аналога того, что сейчас на эту тему можно найти на рынке, который был бы конкурентоспособен за счёт низкой цены.

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

Arduino — простой электронный конструктор, который пользуется заслуженным уважением у любителей, говорят, что его недолюбливают профессионалы, хотя тайком используют в своих жутких экспериментах. В чём секрет его популярности, как воспользоваться ей для решения нашей задачи?

Arduino подходит для локального контроля и управления в доме, в сети есть масса проектов для этого — отлично, но недостаточно, ведь нужно мыслить глобально! Нам нужен выход в сеть и мобильный интерфейс!

Хорошо, что благодаря этой статье мы уже знакомы с OpenHAB — платформой с открытым исходным кодом, объединяющей большое количество устройства с разными протоколами в единую сеть. OpenHAB реализован на Java, поэтому работает в различных ОС, его можно запустить на одноплатном компьютере и даже роутере, в нём есть мобильный и Web интерфейс. Звучит как хороший набор заклинаний против наших, надоевших уже граблей, проверим?

Нехватка времени – одна из наших главных проблем. Причем не хватает его не только на работу, но и на отдых, физический и моральный. Велико искушение «отъесть» недостающие нам часы у такого малопонятного времяпрепровождения, как сон.

Соответственно, недосып – вторая большая проблема для современного человека (и при этом, что характерно, она обычно таки не решает первую). Ложиться спать вовремя зачастую тупо не хочется: есть такое нехорошее ощущение, что тогда в жизни останутся только сон и работа.

Вовремя – это значит резервируя на сон не менее 8-ми часов, как всех нас учили. Но в итоге по факту большинство из нас спит часов 6, а потом «отрывается» в выходные. Но хотя этих 6-ти часов мало для сна, их все еще чересчур много в сутках: желание (и тенденции!) «урезать» сон еще больше – не исчезают. В поисках волшебной таблетки «как мало спать и отлично высыпаться» я, как, наверно, и многие, в свое время натолкнулся на учение о полифазном сне.

Что это?

Все помнят этот фильм? Какого черта он делает на Хабре? И вообще что тут делает подобный пост?
Наверное потому, что я считаю главным звеном в IT все таки человека, а точнее его мозги. Я попробую рассказать еще об одной возможности использовать свой мозг чуточку эффективнее. Одна из слабо задокументированных возможностей, которую мы используем каждый день, но не всегда даже об этом вспоминаем. Все описанное проверялось на мне. Если что-то я не пробовал, но рассказать об этом важно буду отмечать особо. Никаких наркотиков, аппаратов и издевательств над собой, только общедоступные легкие методики (короче, лег проспался и вперед, не вставая даже с кровати).
И да… Это до жути реалистично, на столько, что попробовав, вы не сможете не рассказать об этом.

Что бы не было лишних криков в комментах, попрошу всех кто ярых сторонников любой религии и конфессии, а так же убежденных эзотериков сразу поставить минус в карму и не читать дальше. Здесь не будет философии и великих вселенских тайн. А остальных прошу под кат — попробую рассказать о своей практике разгона мозга с помощью встроенных функций.

В продолжение темы ОС и этих двух постов: «Overclock мозга или внутренняя виртуализация сознания», Патч для гипервизора сознания хотелось бы поделиться своим опытом в данном сабже, а так же мало задокументированной, но зато намного более простой возможностью «прокачать» свой мозг.

TL;DR:
Статья о настройке бекапа линуксовых серверов. В качестве хранилища используется раздел ZFS с включенными дедубликацией и компрессией. Ежедневно делаются снапшоты, которые сохраняются в течение недели (7 штук). Ежемесячные снапшоты хранятся в течение года (еще 12 штук). В качестве транспорта выступает rsync: на сервере он запущен демоном, на клиентах он запускается из crontab.

Речь в статье пойдет о той самой OpenSCADA, которая под Linux и с oscada.org.

Зачем:
• потому что SCADA на самом деле достойна внимания и популяризации;
• в некоторых малобюджетных или маленьких проектах просто безальтернативная;
• судя по статьям про АСУТП на хабре, многим читателям АСУТП представляется черной магией, недо-IT или чем-то похожим (ломают несчастный modbus, мучают WinCC, которая и так еле тарахтит… Люди читают и охают: «Как так можно…. дырявое ПО в промышленности», но никого не удивляет ломание Win95 и 6го ослика. Поломали бы LON шифрованный, OPC, OPC_UA…… А WinCC сама расшаривает папку с проектом с именем вида WinCC_Project_xxxxxx при первом открытии + это вы еще не видели как ее плагин к Excel может намертво винду подвесить при неаккуратной вставке ячеек чуть больше, чем он может за раз осилить!) – добавим ликбеза;

Недавно я открыл для себя удобство отложенного чтения — когда заинтересовавшую статью в сети можно прочитать в любое время, комфортно расположившись c любимым девайсом на диване / пляже / под одиноким деревцем на тропе, ведущей к базовому лагерю у подножья Эвереста. И хотя проприетарных решений для этого хватает (Instapaper, Pocket, Readability), душа настойчиво требовала OpenSource. И вот к какому решению я пришёл после исследования возможных вариантов.

Решение задачи онлайн-вещания с IP-камеры, вообще говоря, не требует применения WebRTC. Камера сама является сервером, обладает IP-адресом и может быть подключена напрямую к маршрутизатору с целью раздачи видео-контента. Так зачем же применять технологию WebRTC?

Есть продукты, которые можно взять и использовать, но с небольшой модификацией «под себя». Так вот система заявок или helpdesk как раз к таким вещам не относится. Точнее, мы для себя не нашли подходящий продукт и решили сделать сами.

В этой статье речь пойдет про Syncthing — новое открытое кроссплатформенное приложение, работающее по модели клиент-сервер и предназначенное для синхронизации файлов между участниками (P2P). Приложение написано на языке Go и по функциональности похоже на BitTorrent Sync.

После обзора нового сервиса мы с вами попробуем установить его на Raspberry Pi и синхронизировать с ноутбуком.

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

Вступление

Так сложилось, что я живу в коттеджном поселке, где нет центрального отопления, а значит, каждый греет свою квартиру самостоятельно. Чаще всего для этих целей используются газовые котлы, метод достаточно дешевый, жаловаться не на что, но есть одна тонкость. Для корректной работы газового котла (внезапно) необходимо наличие газа в трубе.

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

Решение простое — оставить ключи родственникам/друзьям/соседям, чтобы они могли приехать и включить котел, случись какая-нибудь неприятность. Хорошо, если есть сосед, который будет каждый день заходить и проверять, всё ли в порядке. А если нет? Или он тоже решит уехать куда-нибудь на выходные?

Итак, я решил наладить выкладывание показаний счётчика куда-нибудь в Интернет, чтоб я мог находясь где-нибудь в дальней поездке периодически проверять, тратится ли газ, а если вдруг перестанет тратиться, то срочно звонить родственникам/друзьям/соседям (или кому там я оставил ключи), чтобы приехали и нажали кнопку.

Конечно, после простого выкладывания показаний в Интернет я решил не останавливаться на достигнутом и замутил ещё распознавание показаний и графическое представление, об этом читайте в части 2 данного топика.

У нас на предприятии, основным способом оповещения о событиях системы мониторинга Zabbix является email-рассылка. Jabber не прижился ввиду малой распространенности, а СМС устарел (хоть и весьма универсален). Хотелось предложить ещё одну альтернативу, которой и стали push-уведомления.

Сервис Pushbullet уже успел сделать себе имя на платформе Android, а с недавних пор пытается покорить и iOS. Pushbullet умеет слать «пуши» на телефоны, принимать их в браузере (Chrome и Firefox) и из него же снова отправлять. В общем очень удобный и полезный сервис, который плюс ко всему имеет открытый API. Посредством этого API мы и будем отправлять события Zabbix на телефоны сотрудников.

Вроде еще совсем недавно роутеры были обучены только лишь раздавать Интернет по воздуху и проводам. Лучшие из них делали это так хорошо и стабильно, что некоторые хозяева забывали – где вообще стоит эта коробочка с антеннами? Но постепенно функциональность расширялась, и в результате нынешние флагманские модели дадут фору недорогим NAS. С одной стороны, это хорошо: можно купить роутер, подключить к нему внешний диск и получить два устройства по цене полутора. С другой, богатство возможностей потребовало разработки не просто прошивки, а вполне полноценной операционной системы с удобным интерфейсом и набором драйверов.

И вот тут-то начались проблемы. Производители сетевого оборудования изначально ориентировались на людей, просто обожающих командную строку и помнящих наизусть сотни забористых команд. Избавиться от этой ориентации оказалось делом непростым. До сих пор во вполне потребительских моделях встречается дизайн интерфейса в стиле «Инженеры для инженеров». Случаются и рецидивы: например, ZyXEL, заслуженно гордившаяся простым и удобным интерфейсом в первом поколении роутеров Keenetic, выпустила прошивку версии 2.0, где все было усложнено настолько, что тысячам пользователей захотелось побегать по потолку. До сих пор, даже приобретая новые модели Keenetic, многие находят не совсем официальную прошивку версии 1.0 и заменяют ей прогрессивное творение разработчиков ZyXEL.

Добрый день. С недавних пор стал изучать Ruby on Rails. До этого год программировал на c# (asp.net). Переход на руби означал также переход на Ubuntu и тесное взаимодействие с терминалом. Руби изучаю по данному онлайн-учебнику: railstutorial.ru. На борту имею Ubuntu 13.04.

Работа с RoR бод Ubuntu подразумевает много терминальных окон. В одном rails сервер, в другом Guard со Spork, в третьем Ruby-консоль и пр. В интернете наткнулся на программу под названием tmux. Не вдаваясь в подробности скажу, что она позволяем в одном терминальном окне работать с несколькими консолями (да простят меня линуксоиды за терминологию).

Mozilla выпустила инструмент, который наверняка многим облегчит жизнь: это фреймворк RR под Linux для записи и последующего воспроизведения хода выполнения программы. Воспроизведение происходит абсолютно детерминированно, то есть с теми же регистрами и адресами памяти — и неизменно с тем же сбоем (если он был). Другими словами, можно бесконечно гонять тесты, а как только появится баг — не спеша его изучить в офлайне, прокрутив запись сколько угодно раз. Записываются все деревья процессов и потоков.

RR создан для точного воспроизведения багов, которые проявляют себя непредсказуемо. В таких случаях при отладке стандартными средствами нет смысла запускать программу снова: не факт, что баг опять проявится. Эта проблема постоянно портит жизнь разработчикам. Вот почему в Mozilla решили создать такой фреймворк.