Ниже будет приведен список инструментов мониторинга. Есть как минимум 80 способов, с помощью которых ваша машинка будет под контролем.



1. первый инструмент — top

Консольная команда top- удобный системный монитор, простой в использовании, с помощью которой выводится список работающих в системе процессов, информации о этих процессах. Данная команда в реальном времени сортирует их по нагрузке на процессор, инструмент предустановлен во многих системах UNIX.

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.

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

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

Лирика

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

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

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

Часть 1.

Краткий анализ существующих подходов к сильному ИИ.

Когнитивные архитектуры.

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

Читая Хабр в течении последних двух лет, я видел только несколько попыток разработки ОС (если конкретно: от пользователей pehat и iley (отложено на неопределённый срок) и Igor1024 (не заброшено, но пока больше походит на описание работы защищённого режима x86-совместимых процессоров, что бесспорно тоже необходимо знать для написания ОС под x86); и описание готовой системы от alman (правда не с нуля, хотя в этом нет ничего плохого, может даже наоборот)). Мне почему-то думается, что почти все системные (да и часть прикладных) программисты хотя бы раз, но задумывались о написании собственной операционной системы. В связи с чем, 3 ОС от многочисленного сообщества данного ресурса кажется смешным числом. Видимо, большинство задумывающихся о собственной ОС так никуда дальше идеи и не идёт, малая часть останавливается после написания загрузчика, немногие пишут куски ядра, и только безнадёжно упёртые создают что-то отдалённо напоминающее ОС (если сравнивать с чем-то вроде Windows/Linux). Причин для этого можно найти много, но главной на мой взгляд является то, что люди бросают разработку (некоторые даже не успев начать) из-за небольшого количества описаний самого процесса написания и отладки ОС, который довольно сильно отличается от того, что происходит при разработке прикладного ПО.

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

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

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

Вопрос: картинки будут?
Ответ: будут.

Вопрос: какое отношение этот топик имеет к Хабру?
Ответ: он интересен читателям Хабра.

Вопрос: нет, всё-таки, какое отношение имеет топик к тематике Хабра?
Ответ: никакого; просто я считаю, что Хабр — это, прежде всего, определённая аудитория, а не тематика.

Вопрос: почему в блог «Интернет»?
Ответ: потому что Internet is for porn.

Надежная передача данных в Интернете осуществляется на базе протокола TCP (Transmission Control Protocol), спецификация к которому была опубликована почти 30 лет назад. Алгоритм TCP (RFC793), позволяет подключенному устройству адаптироваться для работы в сети на скоростях в пределах десятков мегабит в секунду и задержки до 100 секунд. С бурным развитием новых технологий передачи данных, уже через 10 лет после внедрения стало ясно что производительность протокола не будет хватать для более широких каналов.

Когда на вопрос «кем вы работаете?» я отвечал «разработчиком ПО для SIM-карт», даже технически подкованные люди частенько удивлялись. Многие думают, что SIM-карта это «что-то типа флешки».

В этой статье я постараюсь кратко рассказать что такое SIM-карта (и смарт-карты в общем), зачем она нужна и что у нее внутри.

На самом деле SIM-карта — это частный случай контактной смарт-карты с микропроцессором. По сути, представляет из себя достаточно защищенный микрокомпьютер с CPU, ROM (опционально), RAM и NVRAM (которая выступает в качестве аналога жесткого диска в PC), с аппаратными генераторами случайных чисел и аппаратной реализацией крипто-алгоритмов.

В некотором приближении архитектуру микропроцессорной смарт-карты можно представить так:

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

Продолжаем начатый цикл статей о NDIS. В этом топике рассмотрим версии NDIS, и принципы передачи пакетов между драйверами «стека» и архитектуру NET_BUFFER.

Фонд TED с 1984 года проводит конференции, выбирая для них самые интересные темы и самые инновационные идеи. Например, на первой конференции 1984 года были представлены только что выпущенный Macintosh, инновационный компакт-диск от Sony, математик Бенуа Мандельброт продемонстрировал практическое применение своей теории фракталов, а специалист по искусственному интеллекту Марвин Минский разъяснил новую модель разума.

Каждое выступление (лекция) на конференции TED называется TED Talk и публикуется в онлайне, сейчас на сайте скопилось уже более 400 видеозаписей. Поскольку все они посвящены невообразимо интересным темам, даже сложно предположить, какие пользуются наибольшим интересом у зрителей. Официальный блог TED Blog опубликовал список Топ-20 лекций за все времена по количеству просмотров, собрав статистику с TED.com, Youtube, iTunes, Hulu, встроенных фреймов, количества скачиваний и т.д.

Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

• Нет, тут есть ошибка -> сами гады -> а может все не так и плохо -> ппц -> ладно, давай выкручиваться

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

• Как узнать каждое состояние и предугадать следующее?
• Как помочь выйти себе и собеседнику из цепочки?
• Что не делать, чтобы не усугубить ситуацию?

Ребята с webmasterworld.com решили собрать все факторы, которые учитивает Google при ранжировании сайтов. Официальным представителем было заявлено (еще на тот момент), что их более 200. Пока список выглядит так, не исключено, что некоторые пункты включают в себя несколько факторов.

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

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

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

Оглавление:

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

Как разработать алгоритм, решающий сложную задачу? Многие считают, что для этого нужно «испытать озарение», что процесс этот не вполне рационален и зависит от творческой силы или таланта.

На самом деле решение любой задачи сводится к сбору информации о наблюдаемом объекте. Причем этот принцип применим как для решения самых сложных научно-исследовательских задач, так и для решения прикладных задач. Работа изобретателя напоминает не столько работу волшебника, сколько путешествие первооткрывателя по неизведанной территории. Главное качество хорошего изобретателя – умение собирать информацию.

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

«Мы работаем для того, чтобы вы не боялись летать»


рис 1. Модель Bombardier BD 500 в аэродинамической трубе

Именно такой слоган я как-то придумал для своей работы. Он как нельзя лучше выражает саму суть разработки систем управления самолётом. И, если честно, я бы хотел, чтобы это стало девизом всех разработчиков систем управления современными самолётами по всему миру. Потому что, несмотря на то, что часто можно услышать, что самолёт — один из самых безопасных видов транспорта, тысячи людей по всему миру боятся летать, вцепляются в ручки кресел… А зачастую причина всех страхов — неизвестность. Когда надо доверится такой непрочной конструкции, болтающейся километры над землёй, таким хрупким сплетением проводов и битов кода, скрытой завесой улыбок стюардесс и тайн программного кода. И которую стоит приоткрыть.

Правило №1. Делайте все авторизационные куки HttpOnly

Куки с флагом HttpOnly не видны браузерному коду, а отправляются только на сервер. На практике у вас почти никогда нет необходимости получать их содержимое со стороны клиента (если такая необходимость почему-то у вас возникла — пересмотрите архитектуру авторизации, скорее всего, там что-то не так). А вот злоумышленнику, нашедшему XSS — а XSS так или иначе когда-нибудь где-нибудь найдется — отсутствие HttpOnly на авторизационных куках доставит много радости.

Для тех, кто интересуется вопросами безопасности и уязвимостями Linux, создан обучающий проект exploit-exercises.com с подборкой виртуальных Linux-машин, описаниями уязвимостей, документацией и практическими заданиями.

1. Виртуальная машина Nebula
торрент-файл
прямая ссылка

Самые общие уязвимости, связанные с эскалацией привилегий в Linux: это SUID-файлы, разрешения, состояние гонки (race conditions), метапеременные оболочки, уязвимости $PATH, уязвимости скриптовых языков, ошибки компиляции бинарных файлов.

Родственники жалуются на мусор в почтовом ящике, поэтому я взял, да и локализовал для них NotificationControl.

Получилось вот такое: