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



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

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

Как известно, в современных архитектурах x86(_64) и ARM виртуальная память процесса линейна и непрерывна, ибо, к счастью, прошли времена char near* и int huge*. Виртуальная память поделена на страницы, типичный размер которых 4 KiB, и по умолчанию они не отображены на физическую память (mapping), так что работать с ними не получится. Чтобы посмотреть текущие отображённые интервалы адресов у процесса, в Linux смотрим /proc/<pid>/maps, в OS X vmmap <pid>. У каждого интервала адресов есть три вида защиты: от исполнения, от записи и от чтения. Как видно, самый первый интервал, начинающийся с load address (соответствующий сегменту .text у ELF в Linux, __TEXT у Mach-O в OS X), доступен на чтение и исполнение — очень логично. Ещё можно увидеть, что стек по сути ничем не отличается от других интервалов, и можно быстро вычислить его размер, вычтя из конечного адреса начальный. Отображение страниц выполняется с помощью mmap/munmap, а защита меняется с помощью mprotect. Ещё существуют brk/sbrk, deprecated древние пережитки прошлого, которые изменяют размер одного-единственного интервала «данных» и в современных системах эмулируются mmap’ом.

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

• оптимально управляет уже выделенной памятью;
• значительно уменьшает количество обращений к ядру (ведь mmap / sbrk — это syscall);
• вообще абстрагирует программиста от виртуальной памяти, так что многие пользуются malloc’ом, вообще не подозревая о существовании страниц, таблиц трансляции и т. п.

Довольно теории! Будем щупать malloc на практике. Проведём три эксперимента. Работа будет возможна на POSIX-совместимых операционках, в частности была проверена работа на Linux и на OS X.

Очередная статья от команды разработчиков библиотеки MSLibrary for iOS посвящена довольно популярной теме создания и компиляции кроссплатформенных библиотек.

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

Мы постарались как можно подробнее и систематичнее осветить вопрос, рассмотрев создание библиотеки «с нуля» и упаковку в библиотеку части функционала уже готового проекта. Под кроссплатформенностью или универсальностью мы подразумевали совместимость библиотеки как с симуляторами, работающими на процессоре с архитектурой i386 или x86_64, так и с реальными девайсами, процессор которых, вероятнее всего, имеет архитектуру armv7 или armv64.

1. Создаем проект библиотеки

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

Закончил я онлайновый курс Algorithms: Design and Analysis, Part I на coursera.org

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

Вкратце.

Пару недель назад, необходимо было освежить информацию в голове информацию по структурам данных и алгоритмам для собеседования. Первым делом полез на www.coursera.org, где хотел пробежаться по некоторым лекциям курса Алгоритмы, там же были две сводные таблички, которые в процессе изучения курса взял на заметку — отлично помогали запомнить сложность операций. Но, к моему удивлению, материалы пройденного курса стали недоступны. Быстрое гугление, в надежде, что кто-нибудь выложил лекции на торрентах, к сожалению, не дало результатов. В итоге, я нашел полную коллекцию слайдов по данному курсу. Спешу поделиться. Самое главное, что взял из этих слайдов, — это вышеупомянутые сводные таблички. Думаю многим пригодится.

Известный гуру внутреннего устройства Windows и архитектуры ARM Алекс Ионеску опубликовал на ресурсе GitHub исходный текст базовой части гипервизора (инструмент виртуализации). Гипервизор содержит в себе множество замечательных свойств, включая, компактный размер, поддержку современных архитектур микропроцессоров, минимальное использование ассемблера в исходных текстах, а также комментарии по его использованию. При его разработке упор делался на максимальную компактность.



Опубликованный проект является настоящей находкой для системных программистов, а также исследователей по безопасности, которые интересуются низкоуровневыми функциями ОС. Гипервизор получил название SimpleVisor, поддерживает только современные 64-битные системы и был успешно протестирован на совместимость с такими системами как Windows 8.1 на микропроцессоре архитектуры Intel Haswell, а также Windows 10 на архитектуре Intel Sandy Bridge.

В свете последних топиков, в том числе «Autodesk не будет продавать ПО попавшим под санкции компаниям», появляется ощущение, что маховик абсурда все сильнее раскручивается. Мы не будем осуждать в этом топике политические причины всего этого безобразия, а подумаем немного о том, что произойдет, если внезапно «выключат Google», причем неважно с какой стороны. Также предлагаю рассмотреть один из вариантов забрать себе накопленный контент, используя открытое ПО.

Для начала давайте подумаем, что является наиболее ценным для большинства пользователей сервисов Google? В первую очередь, это личный контент, который хранится в облаке, почта и другие материалы. Во вторую очередь, это сервисы, которым нужно найти замену в кратчайшие сроки. Мы не будем рассматривать нужды профессиональных разработчиков под Android и корпоративные нужды.

Вышел новый релиз персональной облачной платформы ownCloud 9.0.

Я уже писал про ownCloud раньше. Я очень люблю этот комбайн из хранилища данных с синхронизацией, версионированием, галереей, календарем, хранением контактов и прочими плюшками. Серверная часть написана на PHP, поддерживаются протоколы WebDAV, CardDAV, CalDAV. Клиентский софт есть под Linux, OS-X, Windows, мобильных платформы и через web интерфейс. В теории может работать с петабайтными объемами данных.

Сервис может работать в федеративном режиме — есть возможность объединять и линковать независимые ownCloud-инстансы, делиться каталогами и другими данными. В качестве файловой системы можно использовать GPFS, GlusterFS и другие распределенные варианты. Хорошо допилена интеграция в инфраструктуру Amazon.

Changelog:

1. Возможность добавлять комментарии и теги к файлам
2. Новая система уведомлений
3. (Федеративный режим) Автодополнение имен пользователей
4. (Федеративный режим) Списки доверенных серверов
5. Код для дополненией и основных файлов наконец подписан
6. Добавили новую систему обновления
7. Улучшения производительности при совместном доступе к каталогам
8. Новое API для External Storage
9. Различные улучшения системы безопасности

Когда-то давным-давно… Мной была написана статья «Знакомство с libuniset — библиотекой для создания АСУ», были планы по написанию продолжения, но не сложилось. С тех пор, библиотека значительно «подросла» и даже уже вышла версия 2.0, в которой появилось много новых возможностей: удалённый просмотр логов и программных переменных, поддержка различных полезных и не очень протоколов и баз, есть даже «time-machine», но об этом если до этого дойдёт…

Вообщем я собрался силами и решил, что лучше всё это «один раз увидеть» на конкретном примере.

Поэтому, кому ещё интересно, прошу.

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

Многие C++ программисты, пишущие под Windows часто путаются над этими странными идентификаторами как TCHAR, LPCTSTR. В этой статье я попытаюсь наилучшим способом расставить все точки над И. И рассеять туман сомнений.

В свое время я потратил много времени копаясь в исходниках и не понимал что значат эти загадочные TCHAR, WCHAR, LPSTR, LPWSTR,LPCTSTR.
Недавно нашел очень грамотную статью и представляю ее качественный перевод.
Статья рекомендуется тем кто бессонными ночами копошиться в кодах С++.

Вам интересно ??
Прошу под кат!!!

В последнее время всё чаще и чаще слышишь мнение, что сейчас происходит технологическая революция. Бытует мнение, что мир стремительно меняется.



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

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

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

Кто лишится в ближайшие лет десять работы, а у кого будут новые перспективные вакансии.

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

Я хотел бы подарить сообществу Хабра статью, в которой стараюсь дать достаточно полное описание подходов к алгоритмам подсчёта единичных битов в переменных размером от 8 до 64 битов. Эти алгоритмы относятся к разделу так называемой «битовой магии» или «битовой алхимии», которая завораживает своей красотой и неочевидностью многих программистов. Я хочу показать, что в основах этой алхимии нет ничего сложного, и вы даже сможете разработать собственные методы подсчёта единичных битов, познакомившись с фундаментальными приёмами, составляющими подобные алгоритмы.

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



Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.

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

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



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

Open Source проекты с каждым днём набирают всё большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растёт. Всё это даёт огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.

Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «контрибьютинга», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.

Всем начинающим «контрибьютерам», которые столкнулись с похожим проблемами, добро пожаловать под кат.

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

В посте подробно рассматривается техника генерации случайных подземелий. Основной алгоритм генерации, пример работы которого можно посмотреть здесь, используется разработчиками игры TinyKeep. Оригинальный пост от разработчика был размещён на reddit.

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

Вместо равномерно распределённых случайных чисел (какие выдаёт генератор Math.random в большинстве языков), я использую нормальное распределение Парка-Миллера. В результате вероятность появления маленьких комнат превышает вероятность появления больших. Зачем это надо, объясню позже.

Кроме того я проверяю, что соотношение длины и ширины комнаты не слишком велико. Нам не нужны как идеально квадратные комнаты, так и сильно вытянутые.

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

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

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

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

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

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

На самом деле так выглядел бы Ассемблер, если бы он был оружием, но с C тоже надо быть предельно аккуратным

От переводчика:
Данная публикация является переводом статьи-ответа на текст «How to C in 2016». Перевод последнего был опубликован мной в пятницу и вызвал, местами, неоднозначную реакцию сообщества. Наводку на данный «ответ», для поддержания обсуждения вопроса уже в рамках Хабра, дал пользователь CodeRush, за что ему отдельное спасибо.

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