Internet Systems Consortium провёл тестирование производительности DNS-сервера BIND на разных OS. Честно говоря, результаты меня поразили — такого разброса я не ожидал.

OS	Queries/second
Linux Gentoo 2.6.20.7	93,000
Linux Fedora Core 2.6.20.7	87,000
FreeBSD-7-CURRENT 200708	84,000
FreeBSD-6-stable 200708	55,000
FreeBSD 6.2-RELEASE	51,000
Solaris-10 DevelExpr 5/07	50,000
NetBSD-4.0-Beta 200708	42,000
OpenBSD 4.1-snap-20070427	35,000
Windows 2003 Server	22,000
Windows XP Pro64 5.2.3790 SP2	20,000

P.S. Кстати, лично я рекомендую в качестве DNS-сервера использовать djbdns, а не BIND — по соображениям безопасности, хотя, я уверен, по производительности он тоже выигрывает у BIND (много лет назад я это тестировал, и не думаю что ситуация изменилась).

 

Продолжение статьи «Распределённый Авторский Mash-up». В этом выпуске:

• Mash-up — подстава!
  Теги — откровенно об интимном.
  Развитие идеи «Распределённого Авторского Mash-up».
  

Я хочу предложить вашему вниманию идею, которая может решить основную проблему Web 2.0 проектов: падение качества публикуемых материалов и дискуссий со временем.

Если лично Вы не наблюдаете падение качества топиков и комментариев на хабре, то, пожалуйста, отложите чтение и комментирование этого топика до того момента, когда Вам тоже покажется, что качество всё-таки падает.

 

А вы знаете, что в 99% приложений и абсолютно всех CPAN-модулях таймеры и таймауты реализованы неправильно? Не верите? Правильно не верите! Есть, есть один CPAN-модуль, с корректной реализацией таймеров: EV. :) (Кстати, это, похоже, единственный CPAN-модуль из всех, реализующих event loop, который знает о проблеме использования fork вместе с event loop, описывает её в документации и даже пытается как-то решать!)

Проблема в том, что для реализации таймеров и таймаутов используются функции, возвращающие текущее время. А текущее время может быть изменено в любой момент в любую сторону на любую величину — админом или NTP-демоном. Поэтому получается так, что, например, таймаут установленный программой на 30 секунд, может сработать либо через 2 секунды, либо через пару суток — смотря как изменится текущее время после установки таймаута (а в особо запущенных случаях может не сработать никогда).

Единственный надёжный способ работать с таймерами и таймаутами — использовать монотонное время:
use Time::HiRes qw( clock_gettime CLOCK_MONOTONIC );
$now = clock_gettime(CLOCK_MONOTONIC);

Поддержка CLOCK_MONOTONIC была добавлена в Time::HiRes (по моей инициативе :)) два года назад. И вот сегодня я снова, как и два года назад, поискал на CPAN модули с правильной реализацией таймеров и таймаутов… и нашёл только один. :(

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

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

Существуют разные способы реализовать одновременную обработку данных: fork, threads, event loop… и, насколько я понимаю, вместе они уживаются довольно паршиво.

Давайте возьмём event loop и fork. Есть ли смысл использовать их в одном приложении? На первый взгляд — конечно, есть! Event loop будет нормально работать только при условии, что обработчики событий отрабатывают достаточно быстро. И как только какой-то обработчик начинает требовать много времени для работы, первое что приходит в голову — отforkнуть его в отдельный процесс (в принципе есть ещё и нити, но в perl с ними туго, так что этот вариант даже не рассматриваем).

Но это на первый взгляд. А если копнуть глубже…

… с диким грохотом снова упал Pidgin.

Вы спросите — почему с диким грохотом? Ну да, почему упал все и так понимают. Эх… Грохот — это такой звук, который проигрывается скриптом запускающим pidgin, после выхода pidgin. Что-то типа: «pidgin; play грохот.mp3». Ну а как иначе? Без этого я, работая в одном виртуальном desktop, даже не узнаю, что в другом снова упал pidgin.

Интересно, в природе вообще существует надёжный мультипротокольный IM для Linux?

Ответ на Как научиться вставать по будильнику и прочие подобные топики. Я долго крепился, молчал, но всё-таки не выдержал.

Задолбали жаворонки и пропаганда оных! До солнца вставать надо крестьянам, работа у них такая. А мне, и, по статистике (ссылку не дам, ибо такой статистики встречал много, в разных местах, и доверия к ней полного быть в любом случае не может, но — тем не менее), более 60% населения Земли утром вставать херово, и голова лучше работает вечером/ночью.

Нас ломают с детства, заставляя вставать рано в садик/школу/институт/на работу. Нас ломает «общий» график — везде кроме самых крупных городов не то, что ночью, но и даже в 18-19 часов уже нельзя пойти ни в магазин, ни в прочие места общественного пользования (я про всякие гос.учреждения и т.п. :)).

В продолжение темы fullscreen vs window — посвящается программистам-линуксоидам, ностальгирующим по текстовой консоли времён DOS.

Я сделал шрифт для работы в полноэкранном xterm в видеорежиме 1024x768. Размер шрифта 12x24, т.е. при 80-ти колонках с краю остаётся полоса в 1024-12*80=64 пикселя, что неизбежно, т.к. 1024 на 80 нацело не делится. :) Кодировка — koi8-r, содержит 256 символов. Как вы понимаете, шрифт выглядит достаточно крупным, ибо таким он и должен быть.

Прошу заранее прощения, но мне хочется немного разбавить поток прилизанных пресс-релизов, и хвалебных обзоров гугла, в этом блоге, небольшим user experience.

До недавнего времени я к гуглу относился исключительно положительно (не скажу «любил» т.к. не имею привычки влюбляться в сервисы). Но уже довольно давно он меня сильно и регулярно огорчает вот этим:

У меня есть CGIшка, которую хочется запустить под FastCGI.

Она использует фреймвок, который обрабатывает html-шаблоны, выводит ошибки (die) в браузер, делает всяческие редиректы, отдаёт файлы, etc. — всё как обычно. Этот фреймвок, после формирования и вывода ответа на STDOUT, делает exit() — что тоже, в общем, не оригинально.

Этот exit() может быть вызван внутри eval(), а то и нескольких вложенных eval-ов — к примеру, если где-то, в глубине вычислений, CGIшка решает выдать юзеру редирект. Она при этом вызывает функцию фреймвока, он делает print "Location: ..." и exit().

Но под FastCGI exit() делать нельзя.

 

Я начал с того, что выразил желание развеять распространённые опасения в том, что Hardened — это слишком сложно, либо от этого cтрадает стабильность, функциональность или производительность системы. Я уже продемонстрировал, что такое Hardened Gentoo в общих чертах, а теперь пройдёмся детальнее по этим опасениям.

Настройка Hardened состоит из двух частей: настройка ядра, и настройка ролей (RBAC или SELinux). Пример настройки ядра 2.6.20 я сейчас покажу. А RBAC/SELinux я пока не настраивал.

Процесс установки Hardened Gentoo (точнее, апгрейда текущей Gentoo системы в Hardened) выглядит примерно так:

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

Hardened Gentoo — это несколько изменений в компиляторе и ядре, которые увеличивают общую защищенность системы от взлома. Например, hardened-ядро умеет блокировать массу потенциально опасных операций, а hardened-gcc позволяет защитить компилируемые им программы от взлома типовыми методами а-ля переполнение буфера. Грубо говоря, если у вас стоит «дырявая» версия программы X, и её пытается взломать хакер, то в обычной системе у него это получится, а в hardened — не получится, да ещё и в лог запись пойдёт.

Я практически всегда работаю с одной программой одновременно. Это может быть любая программа: текстовый редактор, файловый менеджер, почтовый клиент, аська, mp3 плеер, командная строка, браузер, etc. Наиболее комфортно работать с этой программой когда во-первых ничего не отвлекает, и во-вторых под неё отведен максимум экранного пространства.

Из этих предпосылок естественным путём приходим к работе в режиме «fullscreen»: каждая программа распахнута на полный экран. А для удобства переключения между программами каждая программа запускается на своём виртуальном desktop-е, между которыми можно переключаться по горячим кнопкам Alt+Fx (как текстовые консольки в линухе).

Когда перед нашей фрилансерской группой встала задача документирования проекта, были сформулированы следущие требования:

• Как известно, программисты, обычно, не очень любят писать документацию… поэтому чем проще и комфортнее будет её писать, тем больше вероятность, что её таки будут писать.
  
  • Поскольку мы работаем из дома, то должна быть возможность писать документацию локально, на своей машине.
  • Чтобы это было делать комфортно, нужна возможность использовать для этого любимый текстовый редактор, никаких форм на вебсайтах а-ля вики или систем заточенных под конкретный редактор/IDE.
  • С доступом в инет у всех по-разному, и чтобы исключить ситуацию, когда документация небыла написана исключительно потому, что когда появилось настроение её писать по закону подлости отвалился инет — для написания документации не должен требоваться инет.
• Документация должна быть доступна всем, кто работает над проектом. Это включает как возможность читать её через вебсайт так и работать с ней как с обычными локальными файлами.
• Желательно, чтобы документация поддерживала какой-нить язык разметки и гиперссылки, чтобы её было удобно читать.
• Возможность редактировать документацию из браузера (а-ля вики) желательна, но не очень важна (разработчики будут работать с файлами, так что эта фича может пригодиться в основном клиенту, который врядли будет напрямую править документацию).