Рассмотрим типичную задачу. Есть программа на C или C++ с исходниками. Известно, что при выполнении определенных условий программа начинает отжирать слишком много памяти. Нужно понять, почему это происходит, и по возможности исправить. Инструменты, которые мы рассматривали до этого, например, в заметке Профилирование кода на C/C++ в Linux и FreeBSD, для этого явно не подходят. Спрашивается, что же тогда делать? На помощь приходит Heaptrack!

Сегодня мы поговорим об основах управления пакетами в Arch Linux. В общем и целом, идея напоминает ports и packages из мира FreeBSD. То есть, можно как компилировать софт из исходников, так и ставить бинарные пакеты. Но есть ряд существенных отличий. Итак, давайте же во всем разберемся!

Для PostgreSQL существует множество так называемых high availability решений, наиболее известными из которых, пожалуй, являются repmgr и patroni. Согласно некоторым отзывам, они не слишком удобны в использовании и иногда могут терять данные. Поэтому сегодня мне хотелось бы рассказать о более новом решении под названием Stolon. Разработка Stolon ведется с сентября 2015-го года. Он написан на языке Go, активно паразитирует на Consul или etcd (на выбор пользователя) и из коробки имеет интеграцию с Kubernetes. Но самое главное — он сравнительно прост в использовании и выглядит очень правильно с точки зрения дизайна системы. При правильном использовании Stolon переживает нетсплиты и не теряет данные.

В последнее время я стал замечать, что Ubuntu как-то не особо мотивирует меня разбираться в том, как работает система. Я просто кликаю мышкой, и все работает. А почему оно работает — этого я не понимаю. Другое дело FreeBSD. Но в последнее время FreeBSD разочаровывает меня большим количеством багов, проявляющихся на десктопе (список можно найти в конце этого поста). После недолгой консультации с коллегами, я решил попробовать Arch Linux. Этот дистрибутив в чем-то напоминает FreeBSD (минимализмом, наличием как бинарных пакетов, так и своего аналога портов) и вполне заслуженно славится своим прекрасным wiki-сайтом, который регулярно показывается мне в выдаче Google.

Рассмотрим реальную задачу, с которой мне пришлось не так давно столкнуться. Есть инсталляция FreeBSD. Используется таблица разделов GPT, все лежит на одном-единственном UFS разделе. Проблема — оказывается, чтобы ядро FreeBSD могло записать свою собственную корку, ему требуется swap-раздел. Притом, не обязательно использовать его именно как swap, просто нужен дополнительный раздел без файловой системы. Воспользоваться md или еще какими-то хаками это обойти не выходит.

Простите, у вас не найдется минутки поговорить о спасителе нашем, ассемблере? В прошлой статье мы написали наше первое hello world приложение на асме, научились его компилировать и отлаживать, а также узнали, как делать системные вызовы в Linux. Сегодня же мы познакомимся непосредственно с ассемблерными инструкциями, понятием регистров, стека и вот этого всего. Ассемблеры для архитектур x86 (a.k.a i386) и x64 (a.k.a amd64) очень похожи, в связи с чем нет смысла рассматривать их в отдельных статьях. Притом акцент я постараюсь делать на x64, попутно отмечая отличия от x86, если они есть. Далее предполагается, что вы уже знаете, например, чем стек отличается от кучи, и объяснять такие вещи не требуется.

Сегодня я хотел бы рассказать о некоторых аспектах использования FreeBSD на ноутбуке. А точнее говоря, аспектах, касающихся энергопотребления. Я не стану приводить общие рекомендации, типа «по возможности используйте легковесные консольные приложения (Irssi, Mutt) вместо тяжелых GUI-аналогов», или «отключайте все неиспользуемые вами устройства прямо в BIOS» в предположении, что они и так всем известны, ну или, в крайнем случае, легко гуглятся. Другими словами, далее речь пойдет только о специфичных для FreeBSD моментах.

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

Недавно я выложил на GitHub ZSON, расширение к PostgreSQL для сжатия JSONB. Сжатие происходит путем анализа существующих в базе документов и создания словаря с наиболее часто встречающимися в документах строками. Притом строки могут быть не только именами ключей, но и значениями в массивах, и так далее. В этой статье на примере ZSON мы разберемся, как вообще пишутся расширения к PostgreSQL, как они покрываются тестами, как происходит их установка и удаление, и так далее.

Иногда при отладке программы бывает удобно посмотреть, что она передает по сети. Для решения этой задачи существует множество программ-снифферов. Проблема в том, что иногда они бывают не совсем удобны. Так, tcpdump всегда выводит IP- и TCP-заголовки пакетов, а мне они не всегда интересны. Этого недостатка лишен tcpflow, однако он не работает с UDP и имеет больно уж широкий вывод в консоль. Столкнувшись со всем этим в очередной раз, я решил написать наконец свой маленький основанный на libpcap сниффер, который был бы удобен лично мне. Как оказалось, пишутся такие снифферы очень просто.