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

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

Если интересны подробности: электрика/Интернет/отопление/водоснабжение с нуля — прошу под кат (сори, много фоток).

^{Фото: Jay Mark Johnson}

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

Ни для кого не секрет, что Интернет развивается очень стремительно, потому совсем не удивительно, что последние свободные блоки адресов /8 (IPv4) были распределены администрацией адресного пространства Интернет (IANA) между нуждающимися региональными регистраторами 3 февраля 2011 года. Последний блок /8 был распределен региональным Интернет-регистратором Европы (RIPE) в сентябре 2012 года. Претендовать на получение блока /22, состоящего из 1024 адресов, может только существующий локальный регистратор, который уже ранее получил адреса IPv6. Тысяча адресов — это единственное, на что он может претендовать. Распределение провайдеро-независимых адресов IPv4 прекращено вовсе. В связи с этим получить блок /24 или даже индивидуальный ip-адрес становится все сложнее.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

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

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

Подробные инструкции, которые даются на code.google позволят вам:

• Сжать все многочисленные скрипты JS и стили CSS
• Соединить все полученные файлы в один JS и в один CSS
• Сжать полученные два файла в формат GZIP, который понимают почти все браузеры и умеют распаковывать на лету
• Прописать такой .htaccess, который заставляет браузеры кэшировать данные два файла

Всё это будет происходить при запуске единственного скрипта compress.php

Для примера, результат сжатия скриптов моего сайта:

• JS: сжато в gzip 26 698 B, сжато без gzip 95 796 B, было 120 147 B
• CSS: сжато в gzip 46 049 B, сжато без gzip 160 001 B, было 281 870 B

Получается, что экономия трафика составляет 329 270 B. Но основной выигрыш для скорости загрузки в том, что теперь загружается не 14 файлов, а всего 2 (а это намного быстрее, так как браузер не тратит время на запросы). Причём делается это один раз, а не динамически силами самого сервера (тем более, что не все сервера поддерживают подобное конфигурирование сжатия для экономии ресурсов процессора).

В итоге, получится:

<link rel="stylesheet" type="text/css" href="min/styles_1349888114.cssgz" />
<script src="min/all_1349888114.jsgz" /></script>

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

Алгоритм Диффи — Хеллмана позволяет двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены канал связи. Полученный ключ можно использовать для обмена сообщениями с помощью симметричного шифрования.

Предлагаю ознакомиться с принципом работы алгоритма Диффи – Хеллмана в замечательном видео от Art of the Problem в моем переводе.

30 ноября 2010 года Дэвид Коллиер (David Collier) писал:

Я заметил, что в busybox ссылки разложены по этим четырём директориям.
Есть ли какое-то простое правило, чтобы определить, в какой директории какая из ссылок должна лежать…
К примеру, kill лежит в /bin, а killall — в /usr/bin… Я не вижу никакой логики в таком разделении.

Вы, наверное, знаете, что Кен Томпсон и Дэннис Ритчи создали Unix на PDP-7 в 1969-ом. Так вот, примерно в 1971 они проапгрейдились до PDP-11 с парой дисков RK05 (по 1,5 мегабайта каждый).

Когда операционная система разрослась и перестала помещаться на первом диске (на котором была расположена корневая ФС), они перенесли часть на второй, где располагались домашние директории (поэтому точка монтирования называлась /usr — от слова user). Они продублировали там все необходимые директории ОС (/bin, /sbin, /lib, /tmp ...) и складывали файлы на новый диск, потому что на старом кончилось место. Потом у них появился третий диск, они примонтировали его в директории /home и перенесли туда домашние директории пользователей, чтобы ОС могла занять всё оставшееся место на двух дисках, а это были целых три мегабайта (огого!).

Предисловие

Скорей всего, матерым системным администраторам статья будет не очень интересна. В первую очередь она ориентирована на новичков, а также на людей, которые столкнулись с подобной проблемой — необходимостью удалить огромное количество файлов из одной папки в ОС Linux (Debian в моем случае), а также с закончившимся местом на диске, когда df -h выдает что почти 30% свободно.

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



Но время не стоит на месте, и вот совсем недавно (20 сентября) от Neurowear на YouTube поступил новый рекламный видеоролик, на сей раз — с виляющим искусственным хвостом («Shippo»):



Судя по видео, хвост распознаёт больше вариантов эмоций, чем ушки; кроме того, теперь он наделён геоинформационными возможностями: привязывает эмоции к местности (например, можно найти какое-нибудь место, которое многие считают пригодным для отдыха), показывает их другим пользователям (в том числе через Twitter или Facebook).

Данное решение позволяет вычислять любых ботов, за исключением тех, которые полностью имитируют работу браузера.

Как это работает

Бот запрашивает страницу, например habrahabr.ru/search. Бот не умеет загружать вместе со страницей картинки, скрипты, css и пр. Значит в логе будет отображен запрос к /search/ и всё.
Если на habrahabr.ru/search заходит живой человек через браузер, то вместе с /search/ в лог попадет множество картинок, скриптов, css и пр.

UICloud — это база бесплатных пользовательских интерфейсов с поисковой системой, рейтингом и каталогизатором в которой собрано все от исходников в формате PSD, до готовых решений на HTML, CSS или jQuery: формы, слайдеры, кнопки, календари, элементы и полноценные интерфейсы для мобильных и веб приложений. В проекте уже сейчас можно найти практически все что нужно для облегчения процесса разработки дизайнерам и разработчикам.

На данный момент в базе 23586 элементов и почти тысяча UI-сэтов включающие в себя готовые решения в едином стиле. Проект создан Британской студией Double-J Design целью проекта является создание самой обширной UI базы.

В этой статье я расскажу о том, как, потратив совсем небольшие деньги и немного времени, получить радиоприемник, способный принимать что угодно в диапазоне 60-1700 МГц (радиостанции, звуковое сопровождение ТВ, радиолюбителей, карманные радиостанции и многое другое). Для этого
мы используем DVB-тюнер на чипе RTL2832, работающий в специальном режиме, который можно приобрести за $20 или даже дешевле.

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

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Эту статью я пишу как сотрудник небольшой хостинговой компании. Всё написанное в статье — не мнение компании, а моё мнение как сотрудника техподдержки в целом. Многое из написанного — опыт моих коллег из других компаний. Вероятно, для некоторых, пишу вполне очевидные вещи. Тем не менее, очень часто я встречаю негатив на форумах (что греха таить — и на хабре тоже) относительно работы техподдержки какого-либо хостера. Эта заметка позволит избежать неприятных ситуаций в общении с нами, да и просто ответит на некоторые вопросы «почему так, а не иначе?»

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

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

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

Рад приветствовать всех хабражителей.
В соответствии с новыми требованиями, на работе стали создаваться резервированные каналы связи, при первичной настройке которых, балансировка траффика в EIGRP не заработала, пришлось разбираться с этим интересным вопросом.

Схема сети

Дано:
У нас есть сеть 172.18.230.224/27, назовем её «нашей сетью», из нее передаются очень важные данные в две других сети ID и IE соответственно. Передача должна осуществляться по резервированным каналам связи, то есть у нас есть основной и резервный каналы. Два интересных нюанса:
1) В сеть ID настроена статическая маршрутизация и, sla-monitors и ip load-sharing per-packet, балансировка работает исправно;
2) В сети IE работает протокол динамической маршрутизации EIGRP и при первичной настройке балансировка не заработала, а почему, разберемся далее.

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

Интересно?

Не хватит пальцев на руках (да и на ногах), чтобы пересчитать все фантастические книги, фильмы и игры, где фигурирует энергетическое оружие. Признайтесь, каждому из вас хотелось заиметь подобную штуку, чтобы со зловещим хохотом поджаривать врагов многометровыми искусственными молниями. Товарищ с ником Rob не стал исключением, и под впечатлением от комикса The Five Fists of Science собрал свою собственную Тесла-пушку.

Оружие не стало точной копией пушки из комикса, но от своего литературного прототипа оно выгодно отличается тем, что реально существует. И работает!

Практическим применением знаний о работе с массивами EVA и iLO в серверах ProLiant, которые вы получили чуть раньше, может стать развертывание высокодоступного кластера на vSphere.

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