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

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

На данный момент мой умный дом полностью закончен: серверная часть, web-интерфейс, приложение с виджетами под Android, контроллеры, датчики и исполнительные устройства, алгоритмы, даже собственный скриптовый язык программирования для них.

Но для начала я бы хотел вам рассказать про аппаратную часть «рабочей лошадки» дома – RC-2(room controller). Я давно пишу прошивки под AVR МК, поэтому в качестве мозга нашего контроллера будет известная Atmega 8-16PU, которая есть во всех магазинах радиодеталей. Да, ее старший брат используется в уже надоевшей всем Arduino Uno, но мы будем держаться от нее подальше.

В арифметике натуральных чисел иногда возникает необходимость поиска делителей составного числа N. Простая операция, обратная умножению чисел, на сегодняшний день неизвестна. Ее отсутствие создает определенные трудности при решении некоторых практических задач, особенно, если манипулировать приходится с числами высокой и очень высокой разрядности (сотни и даже тысячи цифр, представляющих числа).

Салют, хабровчане!


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

Пролог

Добрый день, хабраюзер,

Автор данного поста убежден, что движение к совершенству есть череда последовательных небольших шагов. Добиваясь изменения причин происходящих сегодня в отрасли ИБ событий, у нас есть возможность построить такую информационную безопасность с преферансом и барышнями с конкуренцией и инновациями, которую мы все хотим.
Поэтому если вам лень читать дальше, то зайдите на РОИ и проголосуйте. Если не лень — добро пожаловать под кат!

Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).

Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.

Оригинал

Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.

IBM Redbook «Introduction to SAN and System Networking»

Начало

По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.

Привет, Хабр!

Сегодня я хочу рассказать о некоторых решениях проблем, которые возникают во время использования высоконагруженных систем. Все, о чем пойдет речь в этом материале, проверено на собственном опыте: я – Social Games Server Team Lead в компании Plarium, которая занимается разработкой социальных, мобильных, браузерных игр.

Для начала немного статистики. Plarium занимается разработкой игр с 2009 года. На данный момент наши проекты запущены во всех наиболее популярных социальных сетях («Вконтакте», «Мой мир», «Одноклассники», Facebook), несколько игр интегрированы в крупные игровые порталы: games.mail.ru, Kabam. Отдельно существует браузерная и мобильная (iOS) версии стратегии «Правила войны». В базах числятся более 80 миллионов пользователей (5 игр, локализация на 7 языках, 3 миллиона уникальных игроков в день), в итоге все наши серверы получают в среднем около 6500 запросов в секунду и 561 миллион запросов в сутки.

В качестве аппаратной платформы на боевых серверах в основном используются два серверных CPU с 4 ядрами (x2 HT), 32-64 GB RAM, 1-2 TB HDD. Серверы работают на базе Windows Server 2008 R2. Контент раздается через CDN с пропускной способностью до 5 Gbps.
Разработка ведется под .NET Framework 4.5 на языке программирования C#.

Учитывая специфику нашей работы, необходимо не только обеспечить стабильное функционирование систем, но и гарантировать, что они смогут выдержать большой скачок нагрузки. Увы, многие популярные подходы и технологии не выдерживают проверку высокой нагрузкой и быстро становятся узким местом в системе. Поэтому, проанализировав множество проблем, мы нашли оптимальные для нас (как мне кажется) пути их решения. Я расскажу, какие технологии мы выбрали, от каких отказались, и объясню, почему.

Вчера, 24 апреля, был анонсирован релиз NGINX 1.6 и 1.7. Эта статья объясняет, как планируются релизы NGINX и значение этого изменения нумерации версий.

NGINX 1.6 отделился от текущей основной (mainline) ветки 1.5, а последняя была перенумерована в 1.7. Это ежегодное событие, когда берется текущая основная ветка с новой функциональностью и от нее ответвляется новая стабильная (stable) ветка. Разработка активно продолжается на уже перенумерованной основной ветке.


Версия 1.4 более не поддерживается. Основная ветвь 1.5 была форкнута для создания стабильной 1.6 и перенумерована в 1.7.

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

В этой статье мы расскажем о том, как можно получить спецификацию Linux-сервера в командной строке.