Не так давно попалась мне на глаза великолепная юмористическая статья про файловую систему, хранящую данные в числе Пи. Бурное обсуждение, развернувшееся в комментариях (кажется, не все его участники поняли шутку), натолкнуло меня на мысль, что тему нормальных чисел неплохо бы обсудить более серьёзно, тем более что тема эта благодатна, полна красивых результатов, нерешённых проблем и прочих кошерных вещей. Если желаете с этими вещами ознакомиться — пожалуйте под кат.

Давно меня заботила проблема, что пользователь шаред-хостинга не всегда знает, что происходит с его аккаунтом — зашёл ли кто по ftp, выполнилось ли задание cron, был ли доступ по ssh, куда делось письмо и вообще отправлялось ли. У большинства хостеров (и у нас в том числе) пользователь мог задать вопрос в службу техподдержки и ждать, когда специалист с соответствующими правами и квалификацией сделает подборку нужных логов. Бонусная проблема — нельзя вот так просто взять и одной командой посмотреть записи в логах относящиеся к пользователю. Это создаёт трудности для системного администратора.

Казалось бы простая задача с самого начала начала преподносить сюрпризы.

Тех, кто использует или собирается использовать Zabbix в промышленных масштабах, всегда волновал вопрос: сколько реально данных сможет Заббикс «переварить» перед тем как окончательно поперхнется и подавится? Часть моей недавней работы как раз касалось этого вопроса. Дело в том, что у меня есть огромная сеть, насчитывающая более 32000 узлов, и которая потенциально может полностью мониториться Заббиксом в будущем. На форуме давно идут обсуждения о том, как оптимизировать Zabbix для работы в больших масштабах, но, к сожалению, мне так и не удалось найти законченное решение.

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

Всем наверно известен замечательный OpenSource проект Trac, позволяющий организовать рабочий процесс при разработке программного обеспечения. Однако его развертывание и настройка является не простой задачей. Информация в интернете разрозненная и часто уже устаревшая. В этом я смог сам убедиться настраивая Trac интегрированный с Gitolite на связке Nginx+UWSGI.

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

Достаточно давно мне на глаза попались следующие статьи по этой тематике:

• nginx, memcached и SSI
• Nginx + Memcached + SSI — кеширование страниц и блоков (partials)
• Кеширование страниц — ускоряем сайт в 100 раз (Varnish + ESI)

С PHP я дружу, поэтому попробовал примеры и убедился, что это работает. Но всё это имело «фатальные недостатки» :) — PHP, а я фанат Python и по работе занимаюсь в основном бэкендом. Серьёзно говоря, применить на практике это не представлялось возможным.

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

В первую очередь было реализовано черновое решение для моего любимого фрэймворка Flask использующее для кэширования стек Varnish+ESI. Это заработало и даже показало неплохие результаты. Позже пришло понимание, что возможно Varnish «лишний игрок» и всё тоже и даже гибче можно получить на связке Nginx+Memcached+SSI. Был сделан и этот вариант, по производительности особых отличий замечено не было, но последний показался более гибким и управляемым.

Тот проект не вырулил даже на взлетную полосу, или вырулил но без меня. Подумав, я решил «причесать код» и выложить его в OpenSource и на суд общественности.

Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

Поскольку я отношусь к секте Vim, далее мы обсудим неисчерпаемые возможности этого редактора, а также инструменты командной строки, вызываемые прямо из Vim для расширения встроенной функциональности. Некоторые из обсуждаемых дальше принципов могут быть применимы и для Emacs, но не для простых редакторов, вроде Nano.

Введение

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

Эта статья — не набор “волшебных команд” и рецептов (cookbook, как называют такие наборы по-английски), хотя они тут тоже присутствуют, а, скорее, попытка описать, как общие принципы построения эргономичных интерфейсов можно применить в практике использования Vim, чтобы сделать из него удобную и эффективную среду работы с текстами.

Эта статья также не является tutorial’ом для начинающих пользователей Vim, хотя и им (а также пользователям Emacs) может быть интересна, поскольку некоторые упоминаемые принципы являются достаточно общими и действуют не только в системах редактирования текстов, а вообще везде, где идет речь об использовании компьютера для редактирования чего-либо. Тем не менее, я предполагаю, что читатель знаком с основными концепциями, применяемыми в Vim (режимы, регистры, буфера, команды) и не останавливаюсь на их подробном описании.

По умолчанию Vim настроен очень старомодно, и эта настройка подразумевает, что пользователь при работе с текстом будет мыслить метафорами пятидесятилетней давности, как будто бы сейчас заря эпохи UNIX. Однако дизайн Vim позволяет сделать несколько настроек, после которых система станет выглядеть вполне прилично и станет работать весьма эффективно, сочетая в себе полезные черты и древних юниксовых инструментов работы с текстом, и современных WYSIWIG-процессоров, при этом обходя, насколько это возможно, присущие им недостатки. Вот об этих настройках и приемах их использования и пойдет речь.

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

Наверняка почти все читатели Хабра знают оболочки sh и bash. Так же большинство из нас что-то слышали про zsh и tcsh. Однако на этом список существующих оболочек не заканчивается. Условно можно разделить их на три группы:

• Клоны Bourne shell (bash, zsh)
• C shell (csh, tcsh)
• Базирующиеся на популярных языках программирования(psh, ipython, scsh)
• Экзотические, специфические и все остальные

О наиболее интересных из них и пойдет речь.

Я давно читал про них, ещё когда учился основам юникс, но как-то не было нужды с ними работать. И, вот, нужда возникла.

Некая программа (допустим, foo) не умеет писать вывод в stdout, только в файл. Даже "-" в качестве имени файла всего лишь создаёт файл с названием "-" [большинство умных программ под unix знают, что одиночный минус вместо имени файла означает вывод в stdout]. Аналогично она отвергает и /dev/stdout.

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

Нужно их объединить в конвеер.

Некрасивый вариант — использование обычного файла. Записал, прочитал.

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

Выглядит это так:

mkfifo mypipe
cat mypipe | bar &
foo mypipe&
rm mypipe

Хочу просто поделиться недавно найденным сервисом для работы с регулярными выражениями. Да, это еще один сервис. Но у него есть особенность — он позволяет не только составлять регулярные выражения, но и помогает разбирать уже написанные — эдакий regexp-декомпилятор.
Сервис называется Regex101.

Приветствую всех хаброжителей!

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

Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.

Bacula состоит из нескольких демонов, каждый из которых несет свою функциональную нагрузку. На рисунке ниже схематично представлена взаимосвязь этих демонов.

Под хабракатом я опишу все демоны подробно


В моем случае резервному копированию подлежат:

1. Конфигурационные файлы различных демонов со всех серверов.
2. MySQL базы данных.
3. Документооборот с файлового сервера Windows.
4. Различные важные данные с nix серверов(движки сайтов/форумов, etc..)

Практически все согласны, что бакапы делать надо. Но, тем не менее, эта проблема всплывает снова и снова. Недавний опрос продемонстрировал два любопытных момента: во-первых половина из нас бакапы не делает вообще, а во-вторых автору даже не пришло в голову включить в опрос пункт «раз в день». Что же не так с простой, на первый взгляд, задачей — запаковать свои файлы и положить архив в тёплое и сухое место?

Основная проблема в том, что бакап не относится к тем вещам, которые можно сделать не думая! Если попытаться тупо запаковать всё содержимое винта, то во-первых вам негде будет эти архивы (ежедневные! :)) хранить, и во-вторых ваша машина будет круглосуточно заниматься архивированием себя, любимой, вместо выполнения ваших задач. А когда начинаешь думать (что уже непросто), то оказывается, что данные на винте очень разные, и бакапить их желательно тоже по-разному (что окончательно осложняет ситуацию). Как следствие, либо принимается решение не делать бакапы вообще (замаскированное под «отложить на потом»), либо ставится первая попавшаяся утилита и кое-как быстро настраивается, в надежде, что этого будет достаточно.

Польский security-эксперт Michał Sajdak из компании Securitum нашел очень интересный бэкдор в роутерах TP-LINK.

Эксплуатация бэкдора довольна проста, и её суть показана на следующей иллюстрации:

В предыдущей своей небольшой заметке я описывал принцип построения эмулятора старой игровой платформы CHIP-8 из далеких 70-х. Здесь же речь пойдет о своего рода наследнице – CHIP16. Итак, что же такое CHIP16?

CHIP16 – “вымышленная” игровая приставка, которой никогда не существовало в “железе”. Всю спецификацию на нее разрабатывали (-ют) энтузиасты с одного англоязычного форума. Смысл в том, чтобы максимально упростить написание эмулятора, иметь хорошую документацию и поддержку комьюнити. Тем самым позволяя даже новичкам в программировании создать полностью рабочий эмулятор с нуля на фактически любом языке программирования. Сразу оговорюсь, что здесь я не буду приводить примеры кода эмулятора, цель – просто рассказать об этой платформе. И да, конечно все Just for fun!

Извечная мечта «ничего не делать и получать за это деньги» наконец-таки стала доступна не только депутатам.

Мир bitcoin мощными рывками захватывают суперспециализированные устройства для майнинга — ASIC майнеры.

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

Обратной стороной стремительного развития технологий майнинга является резкий рост сложности (и как следствие падение удельной доходности майнинга).



Рост сложности вызывает «Великое Переселение GPU майнеров» — огромная часть сообщества майнеров, использующая для майнинга топовые видеокарты ATI, мигрирует на альтернативные криптовалюты, для которых разработка специализированных чипов для майнинга (пока ещё) экономически не эффективна. Это развивает рынок криптовалют вширь, и останется ли bitcoin криптовалютой будущего или будет заменён со временем на bitcoin 2.0 — это пока что никому неизвестно.

На сегодняшний момент ASIC чипы производятся по 55нм-65нм технологии в США и Китае. Однако уже несколько компаний анонсировали 28нм чипы, которые будут готовы в конце этого года или в начале следующего. Это увеличит мощности ASIC устройств в сотни и тысячи раз, поэтому можно смело запасаться попкорном — 2014 год будет зрелищным.

<далее будет про отечественный ASIC майнер BitFury от Метабанка>

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

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

Есть такая топология (ну, конечно, она совсем не такая, но суть отражает):

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

Мы каждый день находим недорогие билеты для наших пользователей на buruki.ru. Но как устроен рынок авиабилетов «под капотом»?

На первой ступени цепочки стоят авиакомпании — производители продукта.

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