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

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

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

Механические клавиатуры. Путеводитель.

Доброе время суток!
Расскажу я как можно собрать себе радиомодем мощностью 100мВт на 433МГц, по стоимости выходящий примерно на 6-7 долларов. Мощный радиомодем за 200 рублей — заманчиво? Тогда начнём.

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

Все больше российских интернет-проектов хотят сервер в клауде и посматривают в сторону Amazon EC2 и его аналогов. Бегство крупных клиентов на Запад мы воспринимаем как вызов для хостеров рунета. Им бы ведь тоже «свой Amazon», с преферансом и поэтессами. Чтобы удовлетворить спрос хостеров на распределенное хранилище данных для развертывания на относительно маленьких мощностях мы сделали Parallels Cloud Server (PCS).

В посте под катом я расскажу об архитектуре storage-части — одной из главных изюминок PCS. Она позволяет организовать на обычном железе систему хранения данных, по скорости и отказоустойчивости сравнимую с дорогостоящими SAN-хранилищами. Второй пост (он уже готовится) будет интересен разработчикам, в нем пойдет речь о вещах, которые мы узнали в процессе создания и тестирования системы.

С момента публикации первой статьи по моему проекту домашних микросхем прошел (скорее пролетел) год, пора поделится прогрессом и новыми проблемами.

Изначальная цель проекта — научиться изготавливать микросхемы в домашних условиях, состоящие из сотен/тысяч транзисторов (уровня КР580ВМ80А / Z80).

Из-за того, что проект получился достаточно большим по требуемым ресурсам и времени — я решил получить в качестве дополнительного результата — документированный, максимально простой open-source техпроцесс, позволяющий создавать микросхемы в ограниченных условиях. В США, возможно, это было бы хорошим поводом для проекта на kickstarter, но видимо не судьба.

Доброе время суток, Хабр!

Недавно, я приобрел Kindle 4 и обнаружил, что читать на нем pdf не очень удобно из-за того, что шрифт слишком мелкий. Как говорится если нельза, но очень хочется, то можно!

Для экспериментов я создал тестовую pdf страничку, с помощью которой, подбирал различные параметры.

Замечание 1

Для того, что бы максимально использовать весь экран книги, я изменил размеры страницы и межстрочный интервал:

\usepackage{geometry}
\geometry{left=0.2cm}
\geometry{right=0.2cm}
\geometry{top=0.5cm}
\geometry{bottom=1.25cm}

\linespread{0.95}

Версия 1.0. Оригинал

\documentclass[12pt, a4paper]{article}

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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

Коммерческие комплексы подобного рода весьма дороги и далеко не безгрешны, а среди open-source систем присутсвовал явный и откровенный пробел, что просто подталкивало на разработку своего велосипеда. В результате обобщения нашего личного опыта по созданию и эксплуатации сетей, после долгих проб и ошибок появилась система NOC

События и аварии являются неотъемлемым элементом эксплуатации сети. Ежесекундно фиксируются тысячи событий, служба эксплуатации постоянно занята устранением нескольких аварий, еще несколько аварий наверняка где-то есть, но пока не обнаружены и не диагностированы. Оперативная диагностика и обнаружение аварий является весьма сложной задачей, которая может быть решена только комплексом организационно- технических мер. И не последнюю роль в нем играют автоматизированные средства обнаружения и обработки аварий.

Существует немало систем мониторинга, которые выполняют активную проверку сети и сетевых сервисов по протоколам ICMP и SNMP. Быстрый и неправильный ответ – очевиден. Достаточно настроить волшебную систему мониторинга, и наступит полное счастье. Вся обманчивость этого заблуждения понимается со временем. Сначала выясняется, что обнаружение аварий происходит только на тех сервисах, которые поставлены на мониторинг. Хорошо, если удалось накрыть хотя бы основные сервисы. Остальные, увы, будут ставиться на мониторинг в результате горького опыта и ценой запоздалой реакции. Чуть попозже начинается мистика. Что-то явно работает не так, есть жалобы, но система мониторинга говорит, что все в порядке. В чем причина?