Записки программиста

Как известно, во FreeBSD можно использовать пакеты как бинарные, так и собранные из исходных кодов при помощи портов. Устройство портов за последнее время ничем не изменилось. А вот на смену утилитам для управления бинарными пакетами pkg_add, pkg_info и прочим pkg_* в последних версиях FreeBSD пришел новый пакетный менеджер pkg (также известный как pkgng). Данная небольшая заметка рассказывает о том, как им пользоваться.

Многие скажут, что сегодня я выступаю в роли Капитана Очевидности, и будут совершенно правы. Тем не менее, в разных мейлинг листах и чятиках то и дело появляются люди с вопросами типа «посоветуйте мне идеальную базу данных, а то у меня SQL тормозит и вообще все говорят, что MongoDB сейчас в моде». C 2007-го года я успел поработать со многими СУБД, не исключая ряда NoSQL решений, и по данному вопросу я имею сказать следующее.

СУБД является важнейшим компонентом многих современных систем. Поэтому совершенно естественным является желание собрать эту СУБД из исходников самостоятельно с флагами -march=native -O3, не говоря уже о куда более тонкой настойке при помощи скрипта configure. В этом случае вы также можете подобрать компилятор, который лучше оптимизирует конкретную СУБД под ваши конкретные задачи. Не исключено также, что готового бинарного пакета нужной вам версии приложения еще попросту не существует. Наконец, умение самостоятельно собирать и настраивать приложение дает куда более лучшее понимание его работы, чем простое запоминание каталогов с конфигами и логами. В силу названных причин, давайте попробуем разобраться, как собрать из исходников PostgreSQL, а затем настроить его для полноценной работы.

В этом выпуске: где можно найти бесплатную техническую литературу, некоторые интересные компиляторы и интерпретаторы Python, как нарисовать красивую диаграмму для грамматики в Bison, роемся в кроличьих кишках, познаем суть повторного использования кода, и не только. Предыдущие выпуски: январь 2016, декабрь 2015, ноябрь 2015, октябрь 2015.

Прошло три года с тех пор, как я попрощался с FreeBSD, по крайней мере, как с десктопной операционной системой. Сомнений в том, что FreeBSD по большому счету является неплохой серверной ОС, у меня нет. В частности, веб-сервер, отдающий страницы этого блога, работал и продолжает работать на FreeBSD. А вот о том, изменилось ли что-то в мире FreeBSD в отношении десктопов, достоверных сведений нет. Так что, я решил разобраться в текущем состоянии дел самостоятельно, попробовав установить FreeBSD на ноутбук Toshiba Portege Z930-DKS, который все равно сейчас пылится у меня без дела.

Вот некоторые «специалисты» авторитетно заявляют, что самая большая проблема в Linux — это большое количество дистрибутивов, которые прям так сильно отличаются пакетными менеджерами, путями до конфигов и прочим. На самом деле, в 99% случаев используется либо что-то на базе Debian, либо на базе RedHat. Всякие Arch и Gentoo, конечно, тоже существуют, но в основном они существуют на десктопах энтузиастов, а не в продакшене. И сегодня мы с вами убедимся, что отличий CentOS от Debian, с которым мы уже неплохо знакомы, не так уж много. По крайней мере, в вопросах, касающихся управления пакетами.

Пришло время научиться работать с Linux Containers, более известными под названием LXC. Далее мы будем рассматривать LXC в контексте Debian и Ubuntu, но написанное во многом будет применимо и для других дистрибутивов Linux. Мы коснемся не только основ использования LXC, но и узнаем, как настроить bridged сеть, ограничить количество ресурсов, используемых контейнером, и даже осилим unprivileged containers.

Не могу сказать, что я большой фанат Subversion. По-моему, Git прекрасен, и никакие другие системы контроля версий не нужны. Тем не менее, работать с Subversion время от времени приходится, потому что нужно сделать checkout какого-то древнего полумертвого проекта или еще почему-то. Так что, в этой заметке мы рассмотрим основы работы с Subversion, ну и заодно почему он иногда может быть даже интереснее, чем Git. Заметка рассчитана на тех, кто уже имеет опыт использования Git или хотя бы Mercurial.

Сегодня мы поговорим на тему «C против C++». Некоторые читатели данного блога уже знакомы с моей точкой зрения по этому поводу. Когда встает вопрос с формулировкой вроде «похоже, мы решаем задачу, где очень важна скорость выполнения кода, и нужно выбрать между языками C и C++», в последнее время я склонен рекомендовать C. Многие программисты при этом недоумевают, мол «как же так, ведь С++ новее и имеет больше фичей, и вообще C входит в него как подмножество». Поэтому я хотел бы подробно объяснить свою точку зрения один раз в данном посте, так как каждый раз объяснять ее заново занимает ощутимое количество времени.

В крайнем посте, посвященном изучению OpenGL, мы говорили об освещении. Сегодня же мы узнаем, как можно реализовать вывод текста, например, со значением FPS или текущими координатами камеры, «поверх» отрисованной сцены. Вообще, вывод текста — штука очень непростая. В алфавите может быть намного больше 256 символов, если речь идет, например, о китайском языке. Текст может выводиться не только слева направо, но и справа налево или сверху вниз. Не удивительно, что OpenGL, будучи довольно низкоуровневым API, ничего не знает о шрифтах и выводе текста. Думается также, что это одна из вещей, делающих работу локализаторов игр столь волнующей и увлекательной.