Android-фоны однозначно в тренде, но мало кто готов вступать в клуб «кому за 30», где 30 – цена гаджета в килорублях. Специально для них я отыскал все приличные гуглофоны в пределах 12000 рублей. И это было непросто!

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Вместо вступления

С самого раннего детства я интересовался компьютерами. Интерес этот произрастал из игр под MS-DOS в детсадовском возрасте, заканчивая всевозможными олимпиадами по программированию к окончанию школы. Не удивительно, что после школы пошел учиться в технический институт на программиста. Самое странное, что все эти годы я был абсолютно далек от такой замечательной операционной системы, как GNU/Linux. Но полтора года назад, в самом начале первого семестра, я познакомился с парнем (он был незначительно старше меня и поступил в институт уже после техникума — имея опыт работы), который во время одного из разговоров сказал:

«Хочешь начать изучать GNU/Linux? Начни с Linux From Scratch.»

Единственный бумажный дистрибутив

LFS (здесь и далее аббревиатура от Linux From Scratch) – книга, написанная Герардом Бикмансом, описывающая процесс сборки минимального рабочего варианта GNU/Linux из исходных кодов. Почему бумажный? В свое время книгу можно было купить в твердом переплете, что делает «дистрибутив» несколько необычным, не правда-ли? Помимо самой книги, для сборки конечно-же понадобится интернет (или заранее загруженные исходные коды), свободный раздел на жестком диске, и любая операционная система на базе ядра Linux, имеющая компилятор. Лично я всегда использую либо уже собранный дистрибутив LFS, либо полную установку Slackware – в нем есть все необходимое, чего не скажешь про (например) Ubuntu. Конечно, всегда можно загрузить нехватающие пакеты, но ведь мы хотим только-только научиться линуксу? А Slackware даже в своей базовой установке и без конфигурирования предоставляет требуемый инструментарий.

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

• Не ограничивайте общение перепиской
• Объясняйте клиенту рабочий процесс
• Главный вопрос на все случаи жизни: «Какова цель?»

Томер Хонен и Каспар Шимански, Команда качества поиска, Дублин

Нас часто спрашивают, может ли недоступность сайта во время сканирования Googlebot’ом плохо сказаться на видимостЬ сайта в результатах поиска Google. Иногда сайт бывает недоступен по техническим причинам, например когда он закрыт на обслуживание или редизайн. Подобные ситуации, не обозначенные должным способом, могут негативно повлиять на репутацию сайта. Мы не можем гарантировать индексирование или ранжирование, но существуют методы, которые позволяют справляться с запланированным простоем веб-сайта без отрицательного действия на его видимость в результатах поиска.

Например, при запросе страницы сайта вместо возврата кода статуса HTTP 404 (Не найдено) или показа ошибки на веб-странице с кодом статуса 200 (OK), лучше всего возвратить код статуса 503 (Сервис недоступен), который сообщает поисковику, что простой временный. Более того, это позволяет веб-мастерам предоставлять посетителям и ботам информацию о том, когда веб-сайт восстановит свою работу.

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

Ответ сервера кодом состояния 503 может быть хорошим решением и в других ситуациях. Хорошей практикой считается возвращать код состояния 503 «Сервис недоступен» для ошибок сервера, недоступности сайта, перерасхода трафика или страниц-заглушек (в том числе и «Сайт закрыт на реконструкцию»). На случай запланированных простоев сервера, таких как ремонт аппаратного обеспечения, стоит иметь отдельный сервер, который бы возвращал код 503.

Тем не менее, важно не относиться к коду статуса 503 как к постоянному решению проблемы: продолжительная выдача 503 может рассматриваться как знак, что сервер стал постоянно недоступен, в результате чего мы можем удалить URL из индекса Google.

header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Retry-After: Sat, 8 Oct 2011 18:27:00 GMT');

Так может выглядеть информация в header-e при использовании PHP, если вы настроите ответ 503 (Сервис недоступен).

Подобно тому, как можно сделать страницы 404 более полезными для пользователей, следует также правильно настроить сообщения 503, объясняющие пользователям текущую ситуацию и предоставляющие им информацию о том, когда сайт снова будет доступен.

Дополнительная информация о кодах состояния HTTP предоставлена на странице RFC 2616.

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

Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:

--------------------- yum Begin ------------------------ 
 
 Packages Installed:
    lzo2 - 2.02-3.el5.rf.i386
    dnstracer - 1.8-1.2.el5.rf.i386
    openvpn - 2.0.9-1.el5.rf.i386

---------------------- yum End -------------------------

В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.

   Журнал Fortune составил очередной ежегодный список самых лучших компаний в плане условий работы. И для Intel данный список в этом году дважды стал хорошей новостью – если в прошлом году компания лишь замыкала рейтинг (98 место), то в этом году ей удалось потеснить гигантов IT-рынка, таких как Salesforce.com (52), Adobe (65) и Microsoft (72). В общем, в этом году – 51-ое место!


Уютное место на обложке журнала — вместе с Zappos (6), Dreamworks (10) и Google (4).

В продолжение предыдущего топика "Как на самом деле работает мозг". На написание данного поста меня побудила, с одной стороны, замечательная книга «Grooming, Gossip, and the Evolution of Language» Робина Данбара (Robin Dunbar), а с другой — очередная порция «полезных» и «умных» советов в GTD и других блогах.

Для затравки — небольшая логическая задачка. Дан набор карточек; на каждой из них на одной стороне написана буква, на другой — цифра.
На столе лежат четыре карточки: «А», «Д», «5» и «6». Вам говорят: если на карточке (из числа лежащих на столе) на одной стороне гласная, то на обороте — чётная цифра. Какие из карточек достаточно перевернуть, чтобы однозначно подтвердить или опровергнуть это утверждение?

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

Ищут пожарные,
Ищет милиция,
Ищут фотографы
В нашей столице,
Ищут давно,
Но не могут найти…

С. Я. Маршак «Рассказ о неизвестном герое»


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

Мы знаем про очень многие стартапы, но мы по определению не можем объять необъятное. Поэтому мы время от времени объявляем о поиске стартапов по интересующим нас и наших партнеров-инвесторов темам. Объявления о тематическом поиске стартапов – RFS или Request For Startups – мы публикуем на нашей странице в Фейсбуке.

Итак, какие стартапы и зачем мы ищем для стратегических инвесторов?

Вступление

В статье будет рассказано о том, как в кратчайшие сроки познакомиться с основами скриптинга в GIMP на языке Scheme и приступить непосредственно к решению простых практических задач. Данный материал предназначен лишь для тех, кто собирается автоматизировать рутинную обработку здесь и сейчас, не сильно вдаваясь в тонкости и не жертвуя драгоценным временем. Также, статью не рекомендуется использовать в качестве пособия по Scheme отдельно от Script-fu. Связано это с упрощённым стилем программирования в данном материале и отсутствием освещения других немаловажных фактов, которые нас сейчас волнуют гораздо меньше, чем скорость освоения.

Содержание:

1. Что нам понадобится?
2. Коротко о синтаксисе
3. Переменные
4. Функции
5. Списки
6. Регистрация скрипта в GIMP
7. Написание кода
8. Заключение

Часть 1
Часть 3

В части 1 мы создали (немного бесполезное) mochiweb приложение, которое отправяет клиентам сообщение каждые 10 секунд. Мы настроили ядро Linux, и создали инструмент, чтобы установить много соединений для проверки использования памяти. Мы выяснили, что требуется приблизительно 45 Кб для каждого подключения.

В части 2 мы превратим наше приложение во что-то полезное, и уменьшим потребление памяти:
• Реализация маршрутизатора сообщения с login/logout/send API;
• Обновление mochiweb приложения для работы с маршрутизатором;
• Установка распределенной erlang системы, таким образом, мы можем запустить маршрутизатор на различных узлах;
• Создание инструмента тестирования маршрутизатора большим количеством сообщений;
• График использование памяти в течении 24 часов, оптимизация mochiweb приложение для экономии памяти.

Это означает, что мы разделим логику доставки сообщений и mochiweb приложение. В тандеме с утилитой floodtest из части 1 мы можем протестировать работу приложения в условиях, близких к промышленным.
Реализация маршрутизатора сообщения

Часть 2
Часть 3

В этом цикле статей я поделюсь тем, что я узнал опытным путем о том, как Mochiweb обрабатывает большое количество открытых соединений, и покажу, как создать Comet-приложение, используя Mochiweb, где каждое соединение зарегистрировано в маршрутизаторе. Мы закончим рабочим приложением, которое в состоянии справиться с 1000 000 параллельных соединенией, и узнаем, как много памяти нам для этого потребуется.

В части первой:
• Создание простого Comet — приложение, которое посылает клиентам сообщение каждые 10 секунд.
• Настройка ядра Linux для поддержки большого количества соединений.
• Создание тестирующей утилиты для создания большого количества соединений.
• Определение необходимого количества памяти.

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

Предполагается, что Вы знакомы с bash, и немного с Erlang.

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).

На прошлой неделе мы начали публикацию case’ов, помогающих решать проблемы реального бизнеса в реальной жизни. От вас было получено много пожеланий как это продолжать, у нас у самих возникла масса идей и вот, мы продолжаем! Уже немало написано о том, что с 2011 года для малого бизнеса наступят темные времена. Взносы вырастут в 2,5 раза, отчетность придется сдавать новую, больше и в 4 раза чаще, кроме того, нет никакой гарантии, что наши кровные деньги пойдут по назначению и сделают жизнь бабушек, дедушек и детушек лучше. Но что теперь делать бизнесменам? Уходить «в тень»? Закрываться? Бежать из страны?

Большинство способов малозаконны. А можно ли что-то сделать вполне легально и пережить трудное время, пока правительство не одумается и не прекратит «кошмарить» малый бизнес?

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

И вот вчера на одном из серверов скрипт, проверяющий активные соединения, забил тревогу: постоянно висит исходящее соединение на неизвестный хост на порт 433, уже более 9 часов на момент когда я осилил прочитать почту в понедельник утром ;)

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

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

Задача – получение точных данных об источниках конверсий в Интернет-магазине, чтобы иметь представления о реальной отдаче из разных рекламных каналов и их взаимодействии:

• SEO (Яндекс, Google, Rambler, Mail);
• Контекстная реклама (Яндекс.Директ, Google Adwords, Бегун);
• Системы выбора товаров (Яндекс.Маркет, Price.ru и т.п.);
• Прочие источники переходов (сайты партнеров, различные агрегаторы трафика).

Начало здесь.

Накопители

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

1. Вне человека — хаотичная.
2. В накопителе — хаотичная, но собранная в одном месте.
3. В человеке, его записях, файлах — отсортированная.

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

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

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

Чтобы справиться с хаосом, Дэвидом Алленом был придуман простой инструмент — накопитель.

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

Сегодня я решил опубликовать свои шпаргалки, на самые часто встречающиеся ошибки при работе с MySQL.

Предыстория

Я занимаюсь разработкой IFrame приложений для социальной сети ВКонтакте. Самый удобный способ навигации по приложению — это динамическая подгрузка данных, без перезагрузки всей страницы. Раньше я генерил html код который нужно отобразить на сервере, пока не встретил EJS — JavaScript Templates…

EJS — Embedded JavaScript

EJS оказался одним из самых удобных и подходящих мне шаблонизаторов. Он работает, как с одиночными переменными, так и с массивами (читай объектами), присутствует логика (if...else...).