Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

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


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

А если мы не будем ограничиваться одним форматом doc, тогда в качестве бонуса получим возможность просмотра вложенных документов в других форматах, для которых в Windows зарегистрированы стандартные просмотрщики.

Забегая вперед — всё получилось с помощью PyWin32. Правда, неожиданно в процессе пришлось скомпилировать свой пакет для поддержки нужного COM-интерфейса, но обошлось без жертв.

Мне нужен был инструмент. Острый, практичный, универсальный. Отвечающий всем моим требованиям и расширяемый по моему желанию.



Но простой и удобный. Тут надо отметить, что на основной работе я не разработчик, поэтому постоянной среды программирования на рабочем компе не имею и, когда это требуется, пишу на чем придется — bat, JScript, VBA в MSOffice (да, это Windows, корпоративные системы, тут нет bash и perl «из коробки»), макросы в разном ПО и т.д. Все это помогает решить текущую задачу, но уровень и возможности маленько не те, что хотелось бы иметь.

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

Вы скажете, что сейчас есть инструменты на любой вкус и цвет, только выбирай. Лягушка aka TOAD под Oracle, SoapUI для шины и продукты GNU и Apache для всего остального.
Но проблема в том, что все они они специализированы под одну какую-то деятельность, а с другой стороны слишком универсальны — можно сделать многое, но многими действиями. А если возможность в продукте отсутствует, то добавить ее нельзя. Либо продукт закрытый, либо нужно разрабатывать/покупать плагин, либо качать исходники и в них разбираться. А мне нужен был инструмент, в котором простые действия делаются просто, а на сложные сначала тратится немного времени и дальше опять все просто.

Ингредиенты перечисляются по понижению массовой доли: что ближе к началу, того больше по массе. Вещества, которых в составе менее 1% считаются равнозначными для этого списка, и их можно указывать после основных в любом порядке. В РФ по закону указывается всё без исключения (нет ситуации, когда при малом содержании можно пропускать вещество), и на практике это соблюдается. Почему — чуть ниже.

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

Всем привет! В своей прошлой статье я писал об организации модульной системы мониторинга для микросервисной архитектуры. Ничего не стоит на месте, наш проект постоянно растёт, и количество хранимых метрик — тоже. Как мы организовали переход с Graphite+Whisper на Graphite+ClickHouse в условиях высоких нагрузок, об ожиданиях от него и результатах миграции читайте под катом.

У меня дома используется Debian Sid. Большей частью он весьма и весьма хорош, но местами он слишком Bleeding слишком Edge. Например, когда отгружает пакеты, ломающие работоспособность системы. Вчера приехал wpasupplicant, который сломал мне wifi. Я его откатил, но в процессе я подумал, что многие пользователи не умеют этого делать. Рассказ "как откатить плохой apt-get install/upgrade" — в этом посте.

Ситуация

Мы сделали apt-get install что-то, или apt-get upgrade, или даже apt-get dist-upgrade, и после перезагрузки (или даже сразу же) обнаружили, что так нельзя. Сервис не стартует, убрана важная нам фича, кто-то падает и т.д. Мы хотим откатиться. Но вот, незадача — куда именно мы не знаем, потому что какая была версия до обновления мы не знаем.

Все мы любим --help и man. Несмотря на появление многочисленных форумов, Stack Exchange и прочих ресурсов, хорошим тоном в начале решения своих проблем по-прежнему остаётся самостоятельный поиск ответа в официальной документации (и на этих ресурсах вам скорее всего об этом сразу напомнят). Однако лень продолжает двигать прогресс даже там, где не всегда того ожидаешь. Впрочем, это не только лень — бывают и другие аргументы в пользу «упрощений»…

В общем, оказалось, что классический man устраивает не всех. Поэтому появился проект tldr, который, следуя своей расшифровке «Too long; didn't read», решил принести в консоль лаконичную документацию, содержащую только самое главное. Проекту tldr уже больше 3 лет, но про него ещё почему-то не писали на хабре.

В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.

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

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

Железо, в целом, неплохое, просто прошлого поколения. Выкидывать, естественно, было жалко. Тогда я и предложил протестировать EMС ScaleIO. Если коротко, работает это так:



ScaleIO — это софт, который ставится на серверы поверх операционной системы. ScaleIO состоит из серверной части, клиентской части и нод управления. Дисковые ресурсы объединяются в одну виртуальную одноуровневую систему.

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

Собственно ролик (если быть точным, то это демонстрационный мини-фильм).



Весь цикл постобработки и монтажа выполнен с использованием программного обеспечения под управлением ОС Linux.

По-правде говоря, есть один нюанс. Я для подготовки титров сперва использовал AI, запущенный под Wine. Связано это было отчасти с тем, что я, будучи скован врененными рамками, не уделил должное внимание поиску native альтернатив. В действительности, как оказалось, такая альтернатива, вполне лежащая на поверхности, существует. Ниже расскажу подробнее.

Итак, по-порядку.

Небольшая преамбула

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

Я намеренно не хочу затрагивать такие комплексные аспекты, как редактирование изображений и подготовка трехмерных визуализаций в Blender. Так же я не ставлю задачу обучить читателя пользоваться профессиональным инструментарием. Для этого есть документация и масса пользовательских ресурсов. Цели настоящей серии я бы очертил так:

• Устранить предвзятое мнение относительно невозможности использования *nix систем для профессиональной деятельности отличной от работы программиста или администратора сети;
• Показать, что за счет модульности архитектуры *nix систем и использования программного обеспечения с открытым исходным кодом, следующего стандартам POSIX, многие операции, на которые в привычном рабочем окружении я ранее тратил часы а то и дни, могут весьма просто автоматизироваться, либо решатся за считанные минуты;
• Поделиться опытом и показать, какой инструментарий выбирают специалисты (в частности, какой выбрал я в процессе поисков) и какие решения могут быть наиболее приемлемы для тех или иных задач.

Собственно, в качестве первого примера я решил рассмотреть подготовку макета буклетов для двух моих проектов.



_{Это тиражный результат. Прошу прощения за качество снимка, была только настольная лампа под рукой, если кто хочет посмотреть оригинал, вот буклет про GPS аудиогид в PDF формате с редуцированным разрешением растровой графики.}

Ниже я расскажу о ключевых этапах и проблемах, которые пришлось решать в процессе.

Сентября 17го года купил в личное пользование сервер стоимостью 7680$ у поставщика Тиском.
Поставил в Московский ЦОД tech.ru и приступил к эксплуатации.

Фото-отчёт в наличии. Статья состоит из 5 частей:

1. Зачем мне сервер.
2. Выбор конфигурации.
3. Выбор у кого покупать.
4. Выбор у кого размещать.
5. Проблемы с настройкой данного сервера.

Disclaimer

Эта статья содержит некоторое количество программного кода, написанного на языке Python. Ввиду того, что автор статьи по профессии является сисадмином, но не программистом — стиль и качество этого кода, могут вызвать проявление неконтролируемых эмоций у профессионалов. Пожалуйста, немедленно прекратите чтение если вид неаккуратного или неоптимального кода может негативно сказаться на вашем психическом состоянии.

Постановка задачи

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

• RaspberryPi 3 model B
  
• Вебкамера Logitech C270
  
• Карта памяти Kingston microSDHC 16 Гб
• Некоторое количество проводов и адаптеров

Из всего перечисленного, было решено построить систему домашнего видео-наблюдения с функционалом оповещения о вторжении. В качестве платформы был выбран телеграм-бот. Бот имеет следующие преимущества перед другими возможными реализациями (веб, мобильное приложение):

• Не требуется установки дополнительного клиентского ПО
• Серверная часть может работать с приватным IP адресом через NAT, при этом предъявляются минимальные требования к подключению (вплоть до 3G модема)
• Большая часть инфраструктуры находится на стороне сервис-провайдера, который за меня решил вопросы авторизации, безопасности итп...

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

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

Возможно, для вас будет новостью, но разрабатывать мобильные приложения с функционалом, который доступен Java разработчикам, под Android с помощью фреймворка Kivy не просто просто, а очень просто! Именно этого правила я придерживаюсь, создавая свои проекты с Python + Kivy — разработка должна быть максимально простой и быстрой. Как щелчок пальцами.

На новичков подаваемая информация не расчитана, я не буду на пальцах объяснять, что, откуда и куда. Думаю, те, кто читает данную статью, обладают достаточными для понимания материала, знаниями. К тому же, Kivy, как я уже только что написал, очень простой фреймворк и вся документация с примерами использования находится в исходниках!

Движок QPython (и QPython 3) для Android – вещь по-прежнему плохо изученная, и особенно что касается его встроенной библиотеки Scripting Layer For Android (SL4A), она же androidhelper. Эту библиотеку написали несколько сотрудников Google по принципу 20% свободного времени, снабдили ее спартанской документацией, которую почти невозможно найти, и отправили в свободное плавание. Я искал информацию об SL4A по крупицам, но со временем нашел практически все, что мне нужно.

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

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

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

• обеспечивать отказоустойчивость и избыточность;
• легко масштабироваться;
• просто и быстро решать задачу добавления и блокировки пользователей VPN;
• балансировать нагрузку между входными нодами;
• одинаково хорошо работать для клиентов на GNU/Linux, Mac OS X и Windows;
• поддерживать клиентов, которые находятся за NAT.

Готовых решений, удовлетворяющих всем поставленным условиям, не нашлось. Поэтому мы собрали его на базе популярных Open Source-продуктов, а теперь с удовольствием делимся полученным результатом в этой статье.

Всем привет! У меня на работе есть автомобильная парковка. Конечно, цель данной статьи не хвастовство, учитывая тяжелую ситуацию на дорогах с парковочными местами, и не пиар моего руководства о том, что они заботятся о своих сотрудниках (не буду даже упоминать о месте свой работы!), дело совершено не в этом. Суть в том, что мешает любому другому человеку, не имеющему отношения к месту моей работы, припарковаться на этой парковке? А это шлагбаум, ограничивающий въезд и выезд с этой парковки.

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.