Хочу представить обществу программу для сбора и отображения информации о системе под названием Aspia. Программа является открытым аналогом программы Everest. Автор стремится догнать и перегнать ее по функционалу.

Aspia – свободный и бесплатный инструмент для сбора и отображения информации о системе, включая сетевые параметры, аппаратное и программное обеспечение. Собранные данные можно сохранять в HTML-отчет.

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

Обзор практически всех *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 программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Однажды была поставлена задача написать некую небольшую программу, она должна была что-то делать, но при это требовалось максимально усложнить процесс анализа кода при дизассемблировании. Один из методов это убрать из exe все упоминания об используемых WinApi функциях, и было принято решение хранить не названия WinApi функций, а некие хэш-коды, вычисляемые каким-нить несложным алгоритмом. Потом при перечислений всех функций dll библиотеки находить нужные по этим хэш-кодам. Один из часто применяемых способов, это написать небольшую утилитку, подать ей на вход список названий нужных функций, она вычисляет их хэш-коды и на выходе выдает исходник в котором находится готовая таблица с кодами. Потом этот исходник подключается к проекту и дальше во всю используется. Но как всегда вмешалась лень. Лень было писать такую утилитку, да и еще прописывать необходимые действия в make файле. Хотелось чтобы все вычислялось во время компиляции. Вот тогда был брошен взгляд на шаблоны С++ …

Казалось бы — что может быть проще, чем работа с файлами в C++. Но отдельные личности поражают своей находчивостью в поиске наихудшего подхода.
Не стоит делать так:

std::string filepath("C:\\тест");
std::ofstream file(filepath.c_str());

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

Меня всегда завораживала магия программирования — маленькие фокусы, в которых бессмысленный на первый взгляд код делает что-то интересное. Самые известные из них — «подписи», которые выводят на печать короткий текст (обычно имя автора). В прошлый раз я показала несколько таких фокусов, основанных на эзотерических языках программирования, и некоторым читателям они даже пригодились при подготовке новогоднего поздравления :-) Настоящая же магия — это создание таких вещиц на совершенно нормальном языке, который вы используете каждый день, например, на C++ или Java. В этой статье я покажу несколько способов вывести короткий текст с использованием в качестве исходных данных только числовых констант.

Disclaimer: большинство приведенных фокусов основаны на низкоуровневых действиях с памятью, поэтому результаты могут варьироваться в зависимости от архитектуры компьютера и используемого компилятора (я пользуюсь gcc).

C++ спокойно относится к маргинальным манипуляциям с памятью и указателями, поэтому обфускации типа задания строки числом — почти обычное дело :-) Самый простой пример:

Вчера получил письмо примерно следующего содержания:

Мы рады анонсировать бета-релиз Amazon Simple Email Service (Amazon SES) — хорошо масштабируемого и дешевого сервиса для отправки электронной почты для бизнеса и разработчиков. Amazon SES избавляет от необходимости построения собственного дорогостоящего и сложного решения или лицензирования, установки и обслуживания готового решения. Новый сервис интегрируется с другими сервисами Amazon (AWS), упрощая отправку писем из приложений, работающих на таких платформах как Amazon EC2. С Amazon SES не нужно заключать долгосрочные договора и проводить согласования — просто наслаждайтесь низкими тарифами за количество отправленных писем + траффик.

(вторая часть перевода статьи Разоблачение алгоритмов растеризации шрифтов)

Linux

Наследуя худшее

Windows растеризует шрифты плохо, Linux ещё хуже. Во всех Linux-системах, которые я видел, используется FreeType [10] Дэвида Тёрнера, Роберта Вильгельма и Вернера Лемберга. Это отличная библиотека, но способ её использования, к сожалению, нельзя назвать удачным. Типичный скриншот Linux выглядит так:



Вот полный скриншот:
ссылка

Сразу заметна проблема — чёрные пятна в скругленных углах, образовавшиеся в результате сглаживания. Вцелом, можно сказать, что косые штрихи выглядят тяжелее чем вертикальные, что в регультате производит впечатление «грязи». Вы можете возразить, что FreeType и Linux могли бы использовать схожую с ClearType субпиксельную растеризацию, но по мне это не даёт заметных преимуществ.

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

От переводчика

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

Доброго времени суток, уважаемое Хабрасообщество.

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

Пример:

/* Определяем метафункцию HasF, которая позволяет определить наличие функции f() у любого класса. */
DECLARE_IS_VALID_EXPRESSION(
    HasF,
    ( ( U * ) NULL )->f() /* Это выражение компилируемо только если присутствует U::f() */ );
 
struct Foo{ void f(); };    
struct Bar{};
 
BOOST_STATIC_ASSERT( HasF< A >::value );  /* Тут константа HasF< A >::value будет true */
BOOST_STATIC_ASSERT( !HasF< B >::value ); /* Тут константа HasF< A >::value будет false */

Как Вы уже, наверное, догадались мы будем думать как написать макрос DECLARE_IS_VALID_EXPRESSION.

Написание makefile иногда становится головной болью. Однако, если разобраться, все становится на свои места, и написать мощнейший makefile длиной в 40 строк для сколь угодно большого проекта получается быстро и элегантно.

Внимание! Предполагаются базовые знания утилиты GNU make.

Думаю, многие знакомы с весьма необычной игрой Minecraft (справа — пример сгенерированной в ней карты), в которой игрок находится на (практически) бесконечной поверхности Земли и может исследовать окружающий мир с минимальными ограничениями.

Как же автору игры, Notch'у, удалось добиться подобного сходства его случайных «миров» с земными просторами? В этом топике я как раз и рассмотрю один из способов построить искусственный ландшафт такого рода (и вскользь упомяну пару других способов), а также расскажу о моем небольшом усовершенствовании этого алгоритма, позволяющем значительно увеличивать размеры ландшафта без заметных потерь в производительности.

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

Поглядите на этот гиктастический¹ трёхмерный куб светодиодов 8×8×8, созданный пользователем chr на сайте «Instructables»:



Хотите сделать себе такой? Тогда просто последуйте этому *гм* простому DIY-пособию,² и вскорости вы ошеломите своих друзей собственным 3D-LED-кубом!

___________________
¹ _{В первоисточнике — «geektastic» (от слов «geek» — гик и «fantastic» — фантастический).}
² _{В комментариях опубликован перевод этого пособия, который изготовил sir06Will.}

В этой заметке я опишу методы увеличения производительности линуксового маршрутизатора. Для меня эта тема стала актуальна, когда проходящий сетевой трафик через один линуксовый маршрутизатор стал достаточно высоким (>150 Мбит/с, > 50 Kpps). Маршрутизатор помимо роутинга еще занимается шейпированием и выступает в качестве файрволла.

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

Думаю, что ещё более ранние модели отличались совсем просто — они говорили: «Солдат Крис Катарн, убил 10 враг, потратил 342 патрон, получил 0 ранение» и т. п., чем сразу палились.

Ведь до сих пор, несмотря на развитие веба, на многих сайтах можно встретить «50 пользователи», «1 комментарии», «0 сообщения» и т. п. А ведь насколько приятней, когда сайт говорит с тобой на человеческом языке и правильно спрягает слова по числам.

И ведь сделать это совсем несложно.

Приветствую хабраюзеров, в этой статье пойдет речь о внутреннем устройстве компилятора LLVM. О том, что LLVM вообще такое, можно прочитать здесь или на llvm.org. Как известно, LLVM (условно) состоит из трех частей — байткода, стратегии компиляции и окружения aka LLVM infrastructure. Я рассмотрю последнее.

Содержание:

• Сборка LLVM
• Привязка к Eclipse
• Архитектура окружения
• LLVM API
• Оптимизация Hello, World!

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

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

Не знаю, на сколько эти мысли полезные и/или капитанские, если что — скажете :) Но такое я нигде не встречал, к сожалению.

Засыпая и размышляя над очередной идеей, которой потребовался бы хелпдеск/багтрекер подумал: ведь заставлять пользователей пройти через регистрацию, чтобы запостить баг/фичреквест — бесчеловечно. С дрйгой стороны, Анонимусы — тоже не всегда хорошо. И что делать?

Суть вкратце: идеальная форма регистрации — форма логина.
Подробнее и с картинками под катом.

ArduIMU — это реализованный на базе Arduino блок инерциальных датчиков (Inertial measurement Unit) для коптера (спасибо vlady за уточнение). Этот вертолёт имеет на борту 4 инфракрасных датчика и один ультразвуковой, благодаря чему он может автоматически обходить препятствия.

В форумах люди часто упоминают, что 64-битные версии программ поглощают больший объем памяти и стека. При этом обычно ссылаются на то, что размеры данных стали в 2 раза больше. Однако это необоснованное утверждение, так как размер большинства типов (char, short, int, float) в языке Си/Си++ остался прежним на 64-битных системах. Конечно, например, увеличился размер указателей, но ведь не все данные в программе состоят из указателей. Причины роста потребляемой памяти и стека более сложны. Я решил подробнее исследовать данный вопрос.

В данной заметке я поговорю о стеке, а в будущем планирую обсудить выделение памяти и размер двоичного кода. И еще хочу сразу заметить, что статья посвящена языку Си/Си++ и среде разработки Visual Studio.