Valmat's Personal Blog

Печь для бани с дожигом пиролизных газов

2025-10-23T00:07:49+03:00

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

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

Я сам не настоящий сварщик. Варить меня когда-то учил отец. Я немного баловался электродной сваркой, но ничего серьёзного никогда не делал. Но жизнь заставит.

Первым делом купил MIG-проволочный сварочник в Lidl и маску — это обошлось мне примерно в 100 €.

На металлобазе нашёл 4-мм листовое железо. Оно продавалось листами 2×1 м² — пришлось купить лист целиком.

Лист оказался неподъёмным. Чтобы его поднять, пришлось сразу распилить пополам.
Лист обошёлся ещё примерно в 100 €. Половину этого листа я потом удачно продал за 50 €.
Ну и купил сразу пачку катушек со сварочной проволокой.
Итого себестоимость моей печи можно условно считать ~200 €.

Немного потренировался и начал варить.

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

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

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

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

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

В итоге всё получилось очень даже хорошо. Об этом ниже.

Вот немного фоток процесса изготовления:

Сделал съёмную корзину для камней:

А на верхнюю перегородку приварил рёбра жёсткости, которые одновременно являются дополнительными радиаторами:

Первые испытания проводил на улице:

После прогрева дыма вообще не видно:

Сейчас печь уже установлена у меня в бане и выглядит вот так:

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

В общем, я очень доволен результатом. Это был в каком-то смысле эксперимент. И он удался.

Lost in the Middle. Перевод знаменитой статьи

2025-08-30T22:38:23+03:00

Ниже представлен перевод знаменитой статьи Lost in the Middle о том, что номинальная длина контекстного окна – это совсем не то же самое, что и эффективная.

Ссылки:

PDF оригинальной статьи
PDF перевода статьи
Источник: https://arxiv.org/abs/2307.03172

Потерянные в середине: как языковые модели используют длинные контексты

Lost in the Middle: How Language Models Use Long Contexts

Авторы:
Nelson F. Liu*, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang
*Работа частично выполнена в качестве стажёра в Samaya AI.

Аннотация

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

Введение

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

Языковые модели стали важным и гибким строительным блоком в различных языковых технологиях, ориентированных на пользователя, включая разговорные интерфейсы, поиск и суммаризацию, а также совместное написание [Shuster et al., 2022; Thoppilan et al., 2022; Lee et al., 2022].
Эти модели выполняют задачи нижнего уровня в основном через подсказки: вся релевантная спецификация задачи и данные для обработки форматируются как текстовый входной контекст, и модель возвращает сгенерированное текстовое завершение.
Эти входные контексты могут содержать тысячи токенов, особенно когда языковые модели используются для обработки длинных документов (например, юридических или научных документов, истории разговоров и т. д.) или когда языковые модели дополняются внешней информацией (например, релевантными документами из поисковой системы, результатами запросов к базе данных и т. д.; [Petroni et al., 2020; Ram et al., 2023; Shi et al., 2023; Mallen et al., 2023; Schick et al., 2023]).

Обработка этих случаев использования требует, чтобы языковые модели успешно работали с длинными последовательностями.
Существующие языковые модели обычно реализуются с помощью трансформеров [Vaswani et al., 2017], которые требуют памяти и вычислений, увеличивающихся квадратично в зависимости от длины последовательности.
В результате трансформерные языковые модели часто обучались с относительно небольшими оконными контекстами (от 512 до 2048 токенов).
Недавние улучшения в аппаратном обеспечении (например, более быстрые графические процессоры с большим объемом памяти) и алгоритмах [Dai et al., 2019; Dao et al., 2022; Poli et al., 2023; Rubin et al., 2023] привели к появлению языковых моделей с большими оконными контекстами (например, 4096, 32K и даже 100K токенов), но остается неясным, как эти модели с расширенным контекстом используют свои входные контексты при выполнении задач нижнего уровня.

Мы эмпирически исследуем этот вопрос с помощью контролируемых экспериментов с различными современными открытыми (MPT-30B-Instruct, LongChat-13B (16K)) и закрытыми (OpenAI’s GPT-3.5-Turbo и Anthropic’s Claude-1.3) языковыми моделями в условиях, требующих доступа и использования информации в пределах входного контекста.
В частности, в наших экспериментах вносятся контролируемые изменения в размер входного контекста и положение релевантной информации в пределах входного контекста, и изучаются их эффекты на производительность языковой модели.
Если языковые модели могут надежно использовать информацию в пределах длинных входных контекстов, то их производительность должна быть минимально подвержена влиянию положения релевантной информации в контексте входных данных.

Сначала мы экспериментируем с многодокументным вопросно-ответным анализом, который требует от моделей анализа предоставленных документов для нахождения релевантной информации и использования её для ответа на заданный вопрос; эта задача имитирует настройку генерации с дополнением поиска, лежащую в основе многих коммерческих приложений генеративного поиска и вопросно-ответного анализа (например, Bing Chat).
В этом контексте мы контролируем (i)~длину входного контекста, изменяя количество документов в контексте входных данных (аналогично извлечению большего или меньшего количества документов в генерации с дополнением поиска), и (ii)~контролируем положение релевантной информации в пределах входного контекста, изменяя порядок документов, чтобы разместить релевантный документ в начале, середине или конце контекста.

Мы обнаруживаем, что изменение положения релевантной информации в контексте входных данных может существенно повлиять на производительность модели, что указывает на то, что текущие языковые модели не могут надежно получать доступ и использовать информацию в длинных входных контекстах.
Более того, мы наблюдаем характерную U-образную кривую производительности (см. рисунок выше); производительность языковой модели наивысшая, когда релевантная информация находится в самом начале (эффект первичности) или в конце её входного контекста (эффект недавности), и производительность значительно ухудшается, когда модели должны получать доступ и использовать информацию в середине своих входных контекстов (§ QA Results).
Например, когда релевантная информация размещена в середине её входного контекста, производительность GPT-3.5-Turbo на задаче многодокументного вопросно-ответного анализа ниже, чем её производительность при прогнозировании без каких-либо документов (т.е. в закрытой книге; 56.1%).
Кроме того, мы обнаруживаем, что модели часто имеют идентичную производительность с их аналогами с расширенным контекстом, что указывает на то, что модели с расширенным контекстом не обязательно лучше используют свой входной контекст (§ QA Results).

Учитывая, что языковые модели испытывают трудности с извлечением и использованием релевантной информации в задаче многодокументного вопросно-ответного анализа, в какой степени языковые модели вообще могут извлекать из своих входных контекстов?
Мы изучаем этот вопрос с помощью синтетической задачи извлечения ключевых значений, которая предназначена для минимального тестирования базовой способности извлекать совпадающие токены из входного контекста.
В этой задаче моделям предоставляется коллекция пар ключ-значение в формате JSON, и они должны вернуть значение, связанное с определенным ключом.
Подобно задаче многодокументного вопросно-ответного анализа, задача извлечения ключевых значений допускает контролируемые изменения длины входного контекста (добавление большего количества пар ключ-значение) и положения релевантной информации.
Хотя некоторые модели выполняют синтетическую задачу извлечения ключевых значений идеально, другие модели испытывают трудности даже с простым извлечением совпадающих токенов, которые встречаются в середине их входного контекста, и продолжают демонстрировать U-образную кривую производительности.

Чтобы лучше понять, почему языковые модели испытывают трудности с надежным доступом и использованием информации в своих входных контекстах, мы изучаем роль архитектуры модели (только декодер против кодер-декодер), контекстуализации с учетом запроса и тонкой настройки инструкций (§ Why U-shape). Мы обнаруживаем, что:

Кодер-декодер модели относительно устойчивы к изменениям положения релевантной информации в их входном контексте, но только при оценке последовательностей в пределах их максимальной длины последовательности на этапе обучения. При оценке последовательностей, превышающих те, что были видны во время обучения, мы наблюдаем U-образную кривую производительности (§ Architecture).
Контекстуализация с учетом запроса (размещение запроса перед и после документов или пар ключ-значение) обеспечивает почти идеальную производительность в синтетической задаче извлечения ключевых значений, но минимально изменяет тенденции в многодокументном вопросно-ответном анализе (§ Pre-conditioning).
Даже базовые языковые модели (т.е. без тонкой настройки инструкций) демонстрируют U-образную кривую производительности при изменении положения релевантной информации в контексте входных данных.

Наши результаты показывают, что предоставление языковым моделям более длинных входных контекстов — это компромисс: предоставление языковой модели большего объема информации может помочь ей выполнить задачу нижнего уровня, но также увеличивает объем контента, который модель должна анализировать, что может снизить точность.
Чтобы лучше понять этот компромисс на практике, мы проводим тематическое исследование с моделями извлечения-читателя на открытом вопросно-ответном анализе (§ ODQA Case Study).
В отличие от нашей контролируемой задачи многодокументного вопросно-ответного анализа, где контекст всегда содержит ровно один документ, который отвечает на вопрос, ни один или многие из топ $k$ документов могут не содержать ответа в настройке открытого вопросно-ответного анализа.
Когда мы извлекаем из Википедии, чтобы ответить на запросы из NaturalQuestions-Open, мы обнаруживаем, что производительность модели насыщается задолго до насыщения извлечения, что указывает на то, что текущие модели не могут эффективно использовать дополнительные извлеченные документы — использование 50 документов вместо 20 извлеченных документов лишь незначительно улучшает производительность ($\sim$1.5% для GPT-3.5-Turbo и $\sim$1% для Claude-1.3).

Наш анализ дает лучшее понимание того, как языковые модели используют свой входной контекст, и вводит новые протоколы оценки для будущих моделей с длинным контекстом; чтобы утверждать, что языковая модель может надежно использовать информацию в пределах длинных входных контекстов, необходимо показать, что её производительность минимально подвержена влиянию положения релевантной информации в контексте входных данных (например, минимальная разница в наилучшей и наихудшей производительности).
Чтобы способствовать дальнейшей работе по пониманию и улучшению того, как языковые модели используют свой входной контекст, мы выпускаем наш код и данные оценки.
https://nelsonliu.me/papers/lost-in-the-middle

Многодокументный вопросно-ответный анализ

Экспериментальная установка

В задаче многодокументного вопросно-ответного анализа входные данные модели включают (i)~~вопрос, на который нужно ответить, и (ii)~~$k$ документов (например, отрывки из Википедии), где ровно один из документов содержит ответ на вопрос, а $k - 1$ «отвлекающих» документов не содержат.
Эта задача требует от модели доступа к документу, содержащему ответ, в пределах её входного контекста и использования его для ответа на вопрос.

Пример задачи многодокументного вопросно-ответного анализа

Input Context

Write a high-quality answer for the given question using only the provided search results (some of which might be irrelevant).

Document [1](Title: Asian Americans in science and technology) Prize in physics for discovery of the subatomic particle J/ψ. Subrahmanyan Chandrasekhar shared…

Document [2](Title: List of Nobel laureates in Physics) The first Nobel Prize in Physics was awarded in 1901 to Wilhelm Conrad Röntgen, of Germany, who received…

Document [3](Title: Scientist) and pursued through a unique method, was essentially in place. Ramón y Cajal won the Nobel Prize in 1906 for his remarkable…

Question: who got the first nobel prize in physics
Answer:

Desired Answer

Wilhelm Conrad Röntgen

Документ, содержащий ответ, выделен для ясности.

Мы реализуем эту задачу с данными из NaturalQuestions-Open [Lee et al., 2019; Kwiatkowski et al., 2019], которые содержат исторические запросы, отправленные в поисковую систему Google, в сочетании с аннотированными людьми ответами, извлеченными из Википедии.
В частности, мы берем 2655 запросов, где аннотированный длинный ответ является абзацем (в отличие от списка или таблицы).
Мы используем отрывки (кусочки не более 100 токенов) из Википедии в качестве документов в пределах наших входных контекстов.
Для каждого из запросов нам нужен документ, содержащий ответ, и $k-1$ отвлекающих документов, которые не содержат ответа.
Чтобы получить документ, который отвечает на вопрос, мы используем абзац Википедии, содержащий ответ из аннотаций NaturalQuestions.

Чтобы собрать $k-1$ отвлекающих документов, которые не содержат ответа, мы используем систему извлечения (Contriever, дообученную на MS-MARCO; [Izacard et al., 2021]) для извлечения $k-1$ отрывков из Википедии, которые наиболее релевантны запросу и не содержат ни одного из аннотированных ответов NaturalQuestions.

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

Модуляция положения релевантной информации

Input Context

Write a high-quality answer for the given question using only the provided search results (some of which might be irrelevant).

Document [1](Title: List of Nobel laureates in Physics) …
Document [2](Title: Asian Americans in science and technology) …
Document [3](Title: Scientist) …

Question: who got the first nobel prize in physics
Answer:

Desired Answer

Wilhelm Conrad Röntgen

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

Модуляция длины входного контекста

Input Context

Write a high-quality answer for the given question using only the provided search results (some of which might be irrelevant).

Document [1](Title: Asian Americans in science and technology) …
Document [2](Title: List of Nobel laureates in Physics) …
Document [3](Title: Scientist) …
Document [4](Title: Norwegian Americans) …
Document [5](Title: Maria Goeppert Mayer) …

Question: who got the first nobel prize in physics
Answer:

Desired Answer

Wilhelm Conrad Röntgen

Следуя [Kandpal et al., 2022; Mallen et al., 2023], мы используем точность в качестве нашего основного показателя оценки, оценивая, появляется ли какой-либо из правильных ответов (как взято из аннотаций NaturalQuestions) в предсказанном выводе.

Модели

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

Открытые модели:

MPT-30B-Instruct (максимальная длина контекста 8192 токена, ALiBi позиционирование)
LongChat-13B (16K) (расширенное окно контекста LLaMA-13B до 16384 токенов)

Закрытые модели:

GPT-3.5-Turbo (4K токенов) и GPT-3.5-Turbo (16K)
Claude-1.3 (8K токенов) и Claude-1.3 (100K токенов)
GPT-4 (8K) — только подмножество экспериментов

Результаты и обсуждение

Мы экспериментируем с входными контекстами, содержащими 10, 20 и 30 документов.
Ниже — производительность многодокументного вопросно-ответного анализа при изменении положения релевантной информации в пределах входного контекста.

Таблица: Точность языковых моделей в закрытой книге и оракульской настройке

Модель	Закрытая книга	Оракул
LongChat-13B (16K)	35.0%	83.4%
MPT-30B-Instruct	31.5%	81.9%
GPT-3.5-Turbo	56.1%	88.3%
GPT-3.5-Turbo (16K)	56.0%	88.6%
Claude-1.3	48.3%	76.1%
Claude-1.3 (100K)	48.2%	76.4%

Основные выводы

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

Насколько хорошо языковые модели могут извлекать из входных контекстов?

Учитывая, что языковые модели испытывают трудности с извлечением и использованием информации из середины их входных контекстов в задаче многодокументного вопросно-ответного анализа, в какой степени они могут просто извлекать из входных контекстов?
Мы изучаем этот вопрос с помощью синтетической задачи извлечения ключевых значений.

Input Context

Extract the value corresponding to the specified key in the JSON object below.

JSON data:

{"2a8d601d-1d69-4e64-9f90-8ad825a74195": "bb3ba2a5-7de8-434b-a86e-a88bb9fa7289",
 "a54e2eed-e625-4570-9f74-3624e77d6684": "d1ff29be-4e2a-4208-a182-0cea716be3d4",
 "9f4a92b9-5f69-4725-ba1e-403f08dea695": "703a7ce5-f17f-4e6d-b895-5836ba5ec71c", // <--
 "52a9c80c-da51-4fc9-bf70-4a4901bc2ac3": "b2f8ea3d-4b1b-49e0-a141-b9823991ebeb",
 "f4eb1c53-af0a-4dc4-a3a5-c2d50851a178": "d733b0d2-6af3-44e1-8592-e5637fdb76fb"}

Key: “9f4a92b9-5f69-4725-ba1e-403f08dea695” Corresponding value:

Desired Output

703a7ce5-f17f-4e6d-b895-5836ba5ec71c

Экспериментальная установка

Входные данные включают:

сериализованный объект JSON с $k$ парами ключ-значение (UUID)
ключ, для которого нужно вернуть значение

Мы измеряем точность, оценивая, появляется ли правильное значение в предсказанном выводе.

Результаты

Claude-1.3 и Claude-1.3 (100K) почти идеально выполняют задачу на всех длинах контекста.
GPT-3.5-Turbo, GPT-3.5-Turbo (16K) и MPT-30B-Instruct испытывают трудности, особенно при большом количестве пар.
U-образная кривая производительности сохраняется: наименьшая точность — при необходимости извлекать из середины контекста.

Почему языковые модели не устойчивы к изменениям положения релевантной информации?

Мы исследуем роль архитектуры модели, контекстуализации с учетом запроса и тонкой настройки инструкций.

Влияние архитектуры модели

Кодер-декодер модели (Flan-UL2, Flan-T5-XXL) устойчивы к изменению позиции релевантной информации, если длина последовательности не превышает ту, что была на обучении.
При более длинных последовательностях появляется U-образная кривая.

Влияние контекстуализации с учетом запроса

Размещение запроса перед и после данных почти не влияет на тенденции в многодокументном вопросно-ответном анализе, но помогает в синтетической задаче извлечения ключевых значений.

Влияние тонкой настройки инструкций

U-образная кривая наблюдается как у базовой модели, так и у модели после тонкой настройки инструкций.
Тонкая настройка инструкций слегка уменьшает разницу между наилучшей и наихудшей производительностью.

Всегда ли больше контекста лучше? Тематическое исследование с открытым вопросно-ответным анализом

Предоставление языковой модели большего объема информации может помочь, но также увеличивает объем контента для анализа, что может снизить точность.
В экспериментах с NaturalQuestions-Open производительность модели насыщается задолго до насыщения извлечения: использование 50 документов вместо 20 улучшает точность лишь на 1–1.5%.

Связанные работы

Языковые модели с длинным контекстом

Много работ посвящено масштабированию трансформеров по длине контекста: модификации внимания (рекуррентность, аппроксимации, свертки, линейные RNN), ускоренные реализации (FlashAttention), отказ от внимания (RWKV, S4, Hyena).
Оценка часто проводится по перплексии, но точный доступ к знаниям на длинных контекстах — отдельная задача.

Как языковые модели используют контекст?

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

Эффект серийной позиции

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

Заключение

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

Размышления о природе случайности

2025-08-22T00:49:34+03:00

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

Что такое хаотическая и стохастическая случайность?

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

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

Если смотреть чуть шире, к хаотическим можно отнести и системы, которые работают детерминированно, но под влиянием скрытых от нас параметров, которые мы не можем измерить.

Стохастическая или истинная случайность — это когда исход фундаментально непредсказуем. Нет скрытых причин, нет “глубже” уровня, где всё детерминировано. Объективная — значит, не из-за нашего незнания, а реально встроенная в ткань реальности. В классической физике такого нет, но квантовая механика намекает, что, возможно, да.

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

Неравенства Белла: почему они заставляют думать о случайности

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

В упрощённом виде: представьте две частицы, разлетающиеся в разные стороны. Их свойства (спин или поляризация) запутаны — измеришь одну и сразу узнаёшь про вторую. Белл показал: если мир “локально-реалистичен” (свойства существуют заранее, и ничто не влияет быстрее света), то корреляции между измерениями ограничены формулой вроде $|E_1 + E_2 + E_3 - E_4| \leq 2$ (где $E$ — средние корреляции).

Но эксперименты (с 1980-х по 2020-е, включая “без лазеек” в 2015+) показывают значение до $2\cdot\sqrt{2} \approx 2.8$! Это нарушает неравенство. Вывод: либо нет реализма (свойства не существуют до измерения, и исход случаен), либо нет локальности (есть “нелокальное” влияние), либо оба. Для многих это доказательство “объективной случайности” — в квантовой механике вероятности фундаментальны.

Звучит обескураживающе, правда? Но давайте не спешить с выводами — это не конец истории.

Альтернативные взгляды: почему неравенства Белла не закрывают вопрос

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

Суть в том, что неравенства Белла основаны сразу на трёх предположениях:

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

Эксперименты показывают: все три вместе не работают. Но какой из кирпичиков “убрать” — решает каждая интерпретация по-своему. Вот основные альтернативные взгляды:

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

Важно понимать: современные эксперименты очень аккуратны, все основные “лазейки” (например, влияние детекторов) почти полностью закрыты. Но остаётся принципиальный вопрос — действительно ли наш выбор измерения никак не связан с состоянием системы? Проверить это до конца невозможно.

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

Как объяснить объективную случайность

Предположим, что всё-таки Белл прав и объективная случайность действительно существует. Я не сторонник такой идеи, но вполне допускаю, что это может быть правдой, что бы это ни значило.

Допустим, случайность реальна. Как её вписать в картину мира без лишней “магии” и избыточных предположений?

Здесь вступает в силу бритва Оккама: выбираем объяснение с минимальными допущениями. Вместо введения “фундаментальной случайности” как примитива или нелокальности как хака, давайте подумаем шире.

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

Я предлагаю одно простое и минималистичное допущение: всё, что объективно существует, — это информация.
И больше нет ничего.

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

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

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

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

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

В чём отличие от многомировой интерпретации Эверетта

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

Почему это минималистично по Оккаму?

Меньше допущений: Вместо “случайности как сущности” или “нелокальности” — неоспоримая фундаментальность математики. В основе всего — просто комбинаторика.
Вечность и простота: Нет начала и конца. Информация вечна и вообще вне времени.

Выводы

Разумеется, то, что я тут написал, — это не научная теория.
Всё это нефальсифицируемо, как и многие другие интерпретации квантовой механики.
Но эта идея логична и минималистична по Оккаму.

Возможно, она кажется сложной из-за бесконечности. Но стоит вспомнить о фракталах — простое правило может порождать сложное.

В общем, мы не знаем, существует ли объективная случайность, а если существует, то как она реализуется.
А может быть, Белл просто подсвечивает наши пробелы в понимании. Это размышления, а не истина.

LittleVec — легковесная векторная база данных

2025-06-24T12:00:00+03:00

В последние годы векторные базы данных стали неотъемлемой частью современных ИИ-проектов: поиск по embedding, RAG-пайплайны, быстрый семантический поиск и многое другое. Однако, если вы когда-либо пробовали развернуть подобную БД — будь то FAISS, Milvus, Qdrant или аналогичные решения — вы наверняка сталкивались с тем, что даже для небольших экспериментов и pet-проектов такие системы требуют довольно мощного железа. В итоге приходится либо платить за дорогой сервер, либо мириться с низкой скоростью и неудобствами.

Мотивация и цели

Я регулярно разрабатываю прототипы и экспериментирую с RAG-пайплайнами, поэтому мне остро не хватало простой, быстрой и лёгкой векторной БД, которую можно было бы запустить на любом VPS или даже на домашнем мини-компьютере.
Мои цели были такие:

Минимальные требования к ресурсам. Максимум эффективности: чтобы можно было держать миллионы векторов даже на слабых серверах.
Простота запуска и интеграции..
Надёжность хранения. Не хочется терять данные из-за сбоя — значит, нужна проверенная СУБД в основе.
Гибкость. Возможность использовать разные метрики расстояния, хранить дополнительную информацию (payload), работать с несколькими базами одновременно.

Так и родился LittleVec — минималистичная векторная база данных, работающая как плагин для RocksServer и использующая в качестве хранилища сверхнадёжную RocksDB.

Почему это может быть полезно вам?

Экономия ресурсов. LittleVec потребляет всего 15–50 Мб ОЗУ даже на миллионах записей. Это значит, что вы можете запускать полноценную векторную БД даже на бюджетных VPS или в контейнере на локальной машине.
Быстрая интеграция. Минималистичный и понятный API, готовые Docker-образы, поддержка DEB-пакетов — всё, чтобы вы могли быстро начать использовать LittleVec в своём проекте.
Надёжность и скорость. Благодаря RocksDB и оптимизациям на уровне хранения, поиск по миллиону векторов занимает ~60 мс на обычном сервере.

Как использовать LittleVec

1. Установка и запуск

Вариант 1: Docker

Самый простой способ — воспользоваться Docker-образом:

docker pull valmatdocker/littlevec
docker run -d -p 5577:5577 --name littlevec valmatdocker/littlevec

После запуска API будет доступно на 127.0.0.1:5577.

Вариант 2: Установка через DEB-пакет

Если вы предпочитаете запускать сервис напрямую:

Установите RocksServer.
Клонируйте репозиторий LittleVec и соберите DEB-пакет:

git clone https://github.com/valmat/little-vec.git
cd little-vec/build_deb
./build.sh
sudo dpkg -i littlevec_<version>_amd64.deb

Перезапустите RocksServer:

sudo /etc/init.d/rocksserver restart

Вариант 3: Сборка вручную

cd src
make -j
# Поместите little_vec.so в каталог плагинов RocksServer (обычно /usr/lib/rocksserver/plugins)

2. Быстрый старт с API

Создание базы данных

POST /vecdb/create
Content-Type: application/json

{
    "db_name": "my_vectors",
    "dim": 128,
    "dist": "cos"
}

db_name — имя вашей БД (любая строка)
dim — размерность векторов
dist — метрика: cos, qcos, dot_prod, l1, l2 (опционально)

Добавление векторов

POST /vectors/set
Content-Type: application/json

{
    "db_name": "my_vectors",
    "data": [
        {
            "id": "vec1",
            "vector": [0.1, 0.2, ...],
            "payload": {"text": "пример"}
        }
    ]
}

Поиск ближайших векторов

POST /vectors/get/nearest
Content-Type: application/json

{
    "db_name": "my_vectors",
    "vector": [0.1, 0.2, ...],
    "top_k": 5
}

Ответ:

{
    "data": [
        { "id": "vec1", "distance": 0.123, "payload": {"text": "пример"} },
        ...
    ]
}

Удаление векторов

POST /vectors/delete
Content-Type: application/json

{
    "db_name": "my_vectors",
    "data": [
        { "id": "vec1" }
    ]
}

3. Дополнительные возможности

Можно создавать несколько независимых векторных баз.
В каждом запросе указывать свою метрику поиска.
Хранить произвольный payload для каждого объекта.
Получать distance между любыми векторами и объектами по id.
Всё это — по простому HTTP API, легко интегрируется с любым языком.

Заключение

LittleVec — минималистичная, быстрая, экономная и надёжная векторная база данных для экспериментов, прототипов или даже небольших production-сервисов.

Всё открыто, просто и прозрачно — пробуйте, присылайте фидбек и pull requests!

Все вопросы в issue на GitHub!

AI git commit generator

2024-02-07T12:00:00+03:00

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

Поэтому в какой-то момент я просто взял и сделал bash-утилиты, использующие AI для этих вещей: gitai для коммитов и gitaitag для тегов. О них и расскажу ниже.

AI для коммитов и тегов: `gitai` и `gitaitag`

Что это такое?

gitai — это bash-скрипт для Linux и macOS, который помогает создавать информативные git commit-сообщения с помощью OpenAI (или совместимых API). Скрипт не только пишет лаконичные заголовки в прошедшем времени и краткое описание изменений, но и добавляет эмодзи, список затронутых файлов и даже проводит AI-код-ревью с подсветкой потенциальных проблем или улучшений — всё на грамотном английском.

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

Ключевые возможности

`gitai`:

✨ Генерирует commit-сообщения через OpenAI или совместимый API (можно быстро переключиться на xAI и т.д.)
🐞 Проводит AI-код-ревью и вставляет комментарии о возможных багах или улучшениях прямо в коммит
📝 Автоматически резюмирует изменения (diff)
💬 Украсит сообщение релевантными эмодзи
📄 Перечисляет изменённые файлы
💡 Принимает подсказку (hint) для дополнительного контекста
🏷️ Всегда пишет на английском
🔒 Не даст закоммитить, если нет подготовленных изменений
🖊️ Даёт возможность отредактировать сообщение перед коммитом

`gitaitag`:

🚀 Использует любой OpenAI-совместимый API для генерации описания тега
🏷️ Автоматически подбирает следующую версию тега (например, “v1.2.3” → “v1.2.4”)
✍️ Генерирует подробный changelog по всем коммитам с прошлого тега
🤖 Добавляет эмодзи и делает сообщение приятным для чтения
💡 Можно добавить свой hint для более точного описания релиза
🏷️ Всегда генерирует сообщение на английском
✏️ Позволяет вручную подправить текст перед созданием тега
🔒 Не создаёт тег, если нет новых коммитов с прошлого релиза

Требования

Обе утилиты требуют:

ОС: Linux или macOS (Windows не поддерживается)
Зависимости:
- jq (парсинг JSON)
- curl (обычно уже установлен)
- nano (или замените на любимый редактор в скрипте)
- API-ключ OpenAI: переменная окружения $OPENAI_API_KEY

Установка

Установите зависимости:

# Для Debian/Ubuntu и производных
sudo apt-get install jq curl nano

# Для macOS (через Homebrew)
brew install jq curl nano

Скачайте скрипты:

gitai:

curl -o ~/bin/gitai https://gist.github.com/valmat/44822e1b7c6884bebb25b3ff005117fe/raw/gitai.sh
chmod +x ~/bin/gitai

gitaitag:

curl -o ~/bin/gitaitag https://gist.github.com/valmat/cd64141685f2655c4a02d59902962ca3/raw/gitaitag.sh
chmod +x ~/bin/gitaitag

Добавьте ~/bin в $PATH:

Добавьте в ~/.bashrc, ~/.zshrc или аналогичный файл:
```
export PATH="$HOME/bin:$PATH"
```
Перезапустите терминал или выполните source ~/.bashrc (или соответствующий файл).
Установите переменную с OpenAI API-ключом:
```
export OPENAI_API_KEY="sk-...your key here..."
```
Для удобства добавьте эту строку в настройки вашей оболочки.

Использование

Для коммитов — `gitai`:

Перейдите в директорию git-проекта:
```
cd /path/to/your/project
```
Запустите скрипт:
```
gitai
```
Скрипт:
- автоматически выполнит git add для всех изменений,
- сгенерирует commit-сообщение с помощью AI,
- откроет его в редакторе для финального редактирования,
- закоммитит после сохранения.
(Опционально) Можно добавить hint для AI:
```
gitai "Fix for production crash on startup"
```

Для тегов — `gitaitag`:

Перейдите в директорию git-проекта:
```
cd /path/to/your/project
```
Запустите скрипт:
```
gitaitag
```
Скрипт:
- найдет последний тег и предложит следующий (например, “v1.2.3” → “v1.2.4”),
- проанализирует все коммиты после прошлого тега,
- сгенерирует AI-описание релиза с эмодзи,
- откроет его в редакторе для вашего финального взгляда,
- создаст аннотированный тег с этим сообщением.
(Опционально) Можно добавить hint для AI:
```
gitaitag "Major refactor and new API integration"
```

Примечания

Скрипты не поддерживают Windows.
Редактор по умолчанию — nano, можно заменить в скрипте на любой другой.
Если нет изменений (для gitai) или новых коммитов с прошлого тега (для gitaitag), скрипты не будут ничего делать.
Каждый запрос к AI учитывается в биллинге вашего провайдера.

Примеры

# Обычный коммит с помощью AI
gitai

# Коммит с подсказкой для AI
gitai "Refactored backend integration"

# Обычное создание тега с описанием через AI
gitaitag

# Тег с подсказкой для AI
gitaitag "Initial stable version for production"

Ссылки

gitai.
gitaitag.

Утилиты для извлечения изображений и текста из PDF

2023-11-16T12:00:00+03:00

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

Чтобы упростить и ускорить решение этих задач, я написал набор утилит на C++ — PDF2Images. Они позволяют:

Мгновенно извлекать все изображения из PDF-файлов в нужном формате (png, jpg, tiff и др.)
Получать текст с разбивкой по страницам или в один файл
Гибко настраивать параметры извлечения: диапазон страниц, формат выходных файлов, разрешение и пр.
Использовать утилиты в автоматических скриптах и пайплайнах

Я сам ежедневно использую эти инструменты для подготовки скриншотов и текстовых выборок из PDF, а также для построения RAG (Retrieval-Augmented Generation) — когда нужно быстро получить текстовую базу для дальнейшей работы с LLM.

Установка

Для работы потребуется установленная библиотека poppler:

apt install libpoppler-dev

Далее клонируем репозиторий:

git clone --recursive https://github.com/valmat/pdf2images
cd pdf2images

или, если без --recursive:

git clone https://github.com/valmat/pdf2images
cd pdf2images
git submodule update --init --recursive

Переходим в папку src и собираем проект:

cd src
make release

Для debug-сборки можно использовать:

make -j

Извлечение изображений

bin/extract_imgs.bin <input_file.pdf> [options]

Основные опции:

-i, --input — путь к PDF-файлу
-o, --output — папка для сохранения изображений (по умолчанию .)
-e, --ext — формат изображений (по умолчанию png, можно jpg, tiff и др.)
-f, --from — первая страница для обработки (по умолчанию 1)
-l, --lim — количество страниц для обработки (по умолчанию нет ограничений)
-x, --xres, -y, --yres, -d, --dpi — разрешение и dpi
-g, --gray — черно-белый режим
-q, --quiet — тихий режим (без вывода прогресса)

Пример:

bin/extract_imgs.bin -i mydoc.pdf -o imgs -e jpg -f 2 -l 5

Извлечет изображения со 2 по 6 страницу в папку imgs в формате jpg.

Извлечение текста

bin/extract_txts.bin -i <input_file.pdf> [options]

Основные опции:

-i, --input — входной PDF (обязательно)
-o, --out-dir — папка для сохранения текстов (по умолчанию ./)
-O, --out-file — имя выходного файла (если указано, все страницы будут в одном файле)
-f, --from — первая страница для извлечения (по умолчанию 1)
-l, --limit — сколько страниц извлекать (по умолчанию без ограничения)
-n, --nopagebreak — не добавлять разделитель между страницами (актуально при сохранении в один файл)

Пример:

bin/extract_txts.bin -i mydoc.pdf -O all_text.txt -f 1 -l 10

Извлечет текст с 1 по 10 страницу в файл all_text.txt.

Утилиты распространяются под лицензией MIT, исходники доступны на GitHub.

Получение распределений в задачах регрессии

2022-09-20T12:00:00+03:00

Приводится алгоритм нахождения функций распределения в качестве решения задачи регрессии.

В общем виде задачу регрессии можно сформулировать как восстановление зависимости
$\phi: X \to L_1(\Omega)$,
сопоставляющей элементам некоторого фазового пространства $X$ случайную величину $\xi \in L_1(\Omega)$.

Классический подход к решению задачи регрессии состоит в нахождении среднего значения $E[\phi(x)]$ для каждого $x \in X$.

В статье предлагается простой алгоритм оценки распределений случайных величин $\phi(x) \in L_1(\Omega)$.

GitHub

Мотивация

В анализе данных значительное место занимают два класса задач — задачи классификации и регрессии.

Так сложилось, что, хотя эти задачи очень похожи, подход к их решению отличается.

Большинство алгоритмов решения задач классификации позволяют не просто оценить среднее значение $E[\phi(x)]$ для каждого элемента фазового пространства $X$, но и найти плотность распределения.

Для задач регрессии обычно находят лишь некоторую числовую оценку $\widehat{\phi(x)}$, которая, чаще всего, является средним значением, но не находят плотность распределения.

Знание плотности распределения даёт гораздо больше возможностей для принятия решений, чем просто оценка среднего.

Например, для заданной точки $x \in X$ мы можем:

Оценить уверенность прогноза в каждой конкретной точке.
Найти не среднее, а наиболее вероятное значение случайной величины. Это особенно актуально, если распределение $\phi(x)$ является мультимодальным.
Определить доверительный интервал возможных значений оценки $\widehat{\phi(x)}$.
Вычислить любые характеристики распределения, определяемые конкретной задачей и позволяющие более взвешенно и точно принимать решения на основе прогноза модели.

Описание подхода

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

Для простоты опишу подход для одномерной задачи регрессии. В многомерном случае подход аналогичен.

Имеем некоторое фазовое пространство $X$ и закономерность

$$ \phi: X \to L_1(\Omega, \mathbb{R}) $$

$\phi$ сопоставляет случайные величины из $L_1(\Omega)$ точкам фазового пространства $X$.

Таким образом, мы имеем семейство вероятностных мер $\lbrace P_x\rbrace_{x \in X}$, порождаемых закономерностью $\phi$.

Нам нужно построить модель, порождающую параметрическое семейство вероятностных мер

$$ \lbrace Q_{x, \theta}\rbrace_{x \in X, \theta \in \Theta} $$

и найти оптимальное значение параметра $\theta_0 \in \Theta$, дающее наилучшее, в некотором смысле, приближение реальных распределений $\lbrace P_x\rbrace_{x \in X}$:

$$ Q_{x, \theta_0} \sim P_x $$

При этом мы располагаем выборкой точек $\lbrace(x_i, y_i)\rbrace_{i=1}^N$, порожденной $N$ независимыми испытаниями: $x_i \in X$, $y_i = \phi(x_i)$.

$y_i \in L_1(\Omega)$ — являются независимыми случайными величинами. $x_i \in X$, в общем случае, случайными величинами могут и не быть.

Чтобы понять как строить модель, решающую поставленную задачу, посмотрим как она решается в случае задач классификации.

В приведенной выше постановке задачи единственным отличием задачи классификации от задачи регрессии является то, что для задач классификации вероятностное пространство $L_1(\Omega)$ является дискретным.

Когда задача моделирования распределения решается для дискретного $L_1(\Omega)$, т.е. для классификации, реальную плотность распределения приближают функциями вида

$$ \sum_{k=1}^K \mathbf{1}_{A_k} $$

где $A_k \subseteq \Omega$, $\mathbf{1}_{A}$ — характеристическая функция множества $A$.

Именно так мы и поступим.

Только для решения задачи регрессии моделировать лучше не плотность, а функцию распределения. На это есть ряд причин.

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

Во-вторых, плотность распределения должна удовлетворять свойству $\int_{\mathbb{R}} p(t) dt = 1$. Это свойство может быть сложнее удовлетворить при построении модели, чем соответствующее ограничение на функцию распределения:

$$ \lim\limits_{t \to -\infty}F(t) = 0, \ \lim\limits_{t \to +\infty}F(t) = 1. $$

Построение модели

Вместо привычной для регрессии модели

$$ M_{\theta}: X \to \mathbb{R} $$

и последующего нахождения $\theta$ путём оптимизации, будем строить модель, сразу приближающую функции распределения:

$$ M_{\theta}: X \to (\mathbb{R} \to [0, 1]) $$

или, что то же самое:

$$ M_{\theta}: X \times \mathbb{R} \to [0, 1] $$

То есть каждой паре $(x, t)$, $x \in X, t \in \mathbb{R}$, наша модель будет сопоставлять число в интервале $[0, 1]$.

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

Информация о реальном семействе распределений $\lbrace P_x \rbrace_{x \in X}$, которой мы располагаем, отражена в имеющейся у нас обучающей выборке $\lbrace(x_i, y_i)\rbrace_{i=1}^N$.

Эта обучающая выборка порождает набор тривиальных функций распределения $\lbrace F_i\rbrace_{i=1}^N$:

$$ F_i(t) = \begin{cases} 1, & t \geqslant y_i |\ 0, & t < y_i \end{cases} $$

$F_i(t) = 1$, при $t \geqslant y_i$, и $F_i(t) = 0$, при $t < y_i$.

Чтобы уйти от задачи построения модели, аппроксимирующей выборку функций, к хорошо изученной задаче построения модели, аппроксимирующей выборку точек, перейдем от выборки $\lbrace(x_i, y_i)\rbrace_{i=1}^N$ к выборке

$$ \bigcup\limits_{i=1}^N \lbrace(x_i, t_j, F_i(t_j))\rbrace_{j \in J_i} $$

Для этого для каждого $i = 1…N$ случайным образом подберём числа $t_j$ для $j \in J_i$ из некоторого диапазона допустимых значений $y$.

Таким образом, мы снова приходим к классической задаче регрессии, но фазовым пространством для нее будет не исходное пространство $X$, а пространство $X \times Y$, где $Y \subseteq \mathbb{R}$ — множество допустимых значений $y$.

То есть мы получили обычную задачу регрессии для выборки $\lbrace(z_k, u_k)\rbrace_{k=1}^M$, где
$z_k = (x_l, t_s)$, а $u_k = F_l(t_s) \in [0, 1]$, для некоторых $l$ и $s$.

Для решения этой задачи можно применить любой алгоритм обучения с учителем из арсенала методов решения задач регрессии.

Ограничения

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

Пусть

$$ M_{\theta}: X \times Y \to [0, 1], \theta \in \Theta $$

— параметрическое семейство моделей, и $\theta_0$ — оптимальная оценка параметра, дающая приближение реального семейства распределений $\lbrace P_x\rbrace_{x \in X}$, и

$$ M = \lim\limits_{\theta \to \theta_0, \theta \in \Theta} M_{\theta} $$

— итоговая модель.

Тогда должны быть выполнены требования:

Для каждого $x \in X$ $M(x, \cdot): t \to [0, 1] $ — является функцией некоторого распределения.

То есть должны быть удовлетворены следующие условия:

$\lim\limits_{t \to -\infty} M(x ,t) = 0$,
$\lim\limits_{t \to +\infty} M(x ,t) = 1$
$t_1 \leqslant t_2 \Rightarrow M(x, t_1) \leqslant M(x, t_2)$
$M(x, t) \in [0, 1],, \forall t \in \mathbb{R}$

Все эти условия, в общем случае, не обязаны выполняться по построению моделей $M_{\theta}$ способом, описанным выше.

Условие (3) может быть удовлетворено путём наложения ограничений на саму модель. Например, для нейронных сетей можно последним слоем разместить сигмоиду.

Практика показала, что для правильно построенной модели при достаточном объеме обучающей выборки условия (1) и (2) будут выполнены автоматически. Но эти условия должны быть вынесены на этап валидации в качестве дополнительного обязательного критерия правильности построения модели.

Итоговый алгоритм

Кратко опишем алгоритм.

Дана обучающая выборка $\lbrace(x_i, y_i)\rbrace_{i=1}^N$.

Находим диапазон допустимых значений $Y$.
Например, $$ Y = [\min\limits_{i} y_i - a, \max\limits_{i} y_i + a], $$ где $a$ — некоторое число, подбираемое исследователем.
Для каждой пары $(x_i, y_i)$ случайно генерируем набор точек $\lbrace t_j\rbrace_{j \in J_i} \subseteq Y$.
$\lbrace t_j\rbrace$ нужно генерировать так, чтобы было достаточно точек, лежащих левее $y_i$ и достаточно точек, лежащих правее $y_i$.
Можно задать разбиение $\lbrace t_j\rbrace_{j \in J} \subseteq Y$ одинаковое для всех $i$, но тогда мы теряем разнообразие обучающей выборки в тех случаях, когда $(x_i, y_i)$ и $(x_k, y_k)$ — близкие, но не совпадающие точки.
После того, как точки $\lbrace t_j\rbrace_{j \in J_i}$ сгенерированы, генерируем новую обучающую выборку, как объединение выборок:

$$ \bigcup\limits_{i=1}^N \lbrace(x_i, t_j, u_{i j})\rbrace_{j \in J_i} $$

где

$$ u_{i j} = \begin{cases} 1, & t_j \geqslant y_i |\ 0, & t_j < y_i \end{cases} $$

$u_{i j} = 1$, при $t_j \geqslant y_i$, и $u_{i j} = 0$, при $t_j < y_i$.

Для удобства обозначим $z_{i j} = (x_i, t_j)$.
$z_{i j}$ будут лежать в области определения нашей модели, т.е. будут являться признаками, а $u_{i j}$ в области значений, т.е. будут являться таргетами.
Новую полученную выборку лучше случайно перемешать, перед тем как приступать к обучению модели.
Строим модель обучения с учителем на обучающей выборке $\lbrace(z_{i j}, u_{i j})\rbrace$ как для обычной задачи регрессии.
Проводим валидацию модели.
В частности, на удовлетворение условия того, что $M(x, t)$ является функцией распределения по $t$ для каждого $x \in X$, т.е. проверяем (1), (2), (3).

Валидация

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

В любом случае, модель $M(x, t)$ должна быть функцией распределения по $t$ для всех $x \in X$. Если ограничения (1), (2), (3) не выполнены для $M(x, \cdot)$, то такую модель следует отвергнуть как некачественную.

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

Для получения этих метрик тестовую выборку $\lbrace(x_i, y_i)\rbrace$ нужно привести к виду $\lbrace(z_{i j}, u_{i j})\rbrace$ тем же способом, что и обучающую.

Кроме того, мы можем перейти на уровень исходных данных и для каждой $x_i$ из тестовой выборки посчитать среднее значение $\widehat{y_i}$ как

$$ \widehat{y_i} = \int\limits_{t \in Y} t, dM(x_i, t) $$

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

Замечу, что в некоторых случаях вместо оценки среднего $\widehat{y}$ более уместным будет оценивать наиболее вероятное значение $y$:

$$ \widehat{y_i} = \arg\max \limits_{t \in Y} \frac{\partial M(x_i, t)}{\partial t} $$

В целом, подход с моделированием распределений вместо моделирования значений даёт не меньше, а даже больше способов оценки качества модели.

Эксперименты

В качестве базовой закономерности возьмём функцию

$$ f(x) = 1 - x^2 + \frac{3}{2} x - \sin(2 \pi x^2) $$

на отрезке $x \in [0, 1]$.

Моделируем
Исходный код экспериментов.

Закономерность определяется выражением выше плюс нормальный шум $\mathcal{N}(f(x), \sigma(x))$, где

$$ \sigma(x) = 0.05 + \frac{x}{2} $$

То есть для каждой точки $x \in [0, 1]$ нашего фазового пространства значения соответствующей случайной величины, определяемой моделируемой закономерностью, распределены по закону:

$$ \mathcal{N}(f(x), \sigma(x)) $$

На рисунках ниже:

(a) моделируемая закономерность
(b) решение обычной задачи регрессии

Все функции распределения для всех точек:

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

Нахождение распределений методом, описанным в настоящей статье, тоже даёт хорошие результаты.

Заключение

На практике, при достаточном объеме обучающей выборки, непрерывные алгоритмы машинного обучения, такие как нейронные сети, дают хорошее приближение для функций распределения.

В обучающей выборке могут быть образцы с близкими значениями признака $x$, но различными значениями таргета $y$. Все они вносят вклад в обучение функций распределения.

Эксперименты и практический опыт показывают, что ограничения, накладываемые на функцию распределения, удовлетворяются.

Прогнозирование распределений вместо прогнозирования средних значений даёт намного более богатые возможности для принятия решений.

Моделирование распределений вместо моделирования значений требует меньше дополнительных и часто невыполнимых ограничений.

Например, если рассмотреть решение одной и той же задачи моделированием распределений
$M_{\theta}(x, t) \in [0, 1]$ и моделированием значений $R_{\theta}(x) \in \mathbb{R}$, то применение МНК, то есть MSE в качестве функции потерь, для $R_{\theta}(x)$ равносильно предположению

$$ M_{\theta}(x, t) \sim \mathcal{N}(t , \widehat{y}, \sigma) $$

что, чаще всего, неверно.

Конечно, для нахождения оптимальной модели $M_{\theta_0}(x, t)$ мы тоже вынуждены сделать некоторое предположение на вид распределения ошибки $M_{\theta_0}(x, t) - \widehat{u}$ но это предположение ограничивает нас менее жёстко.

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

Действительно, нам нужно выучить не просто среднее, но и дополнительную информацию о форме распределения.

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

Это дополнительно приводит к замедлению обучения и требует больше вычислительных ресурсов.

Бенчмарк энтропий Шеннона и Реньи на C++

2022-02-08T12:00:00+03:00

Решил сравнить как различные показатели энтропии Реньи влияют на производительность в плане вычислений.

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

Для этого важно понимать, как различные показатели энтропиивлияют на время выполнения.

Определение угла наклона текста на сканированных изображениях

2022-02-08T12:00:00+03:00

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

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

Идея

Базовая идея алгоритма состоит в том, что при повороте текста на сканированном изображении средняя, по строкам и столбцам, энтропия распределения пикселей должна возрасти.

Предположим, нам дан чёрно-белый скан изображения. То есть, каждый пиксель может принимать только два значения: 0 или 1. Как известно, энтропия равномерного распределения максимальна. Если изображение повёрнуто, то в среднем, распределение чёрных и белых пикселей по строкам (и столбцам) будет ближе к равномерному, чем у неповёрнутого изображения. У выровненного изображения распределение пикселей в среднем должно быть менее равномерным.

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

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

Предложенный подход работает и позволяет абсолютно точно определить угол поворота в 83% случаев и с точностью до 1° — в 98% случаев.

Хотя, на первый взгляд, энтропия Шеннона хорошо подходит для этой задачи, было бы разумно не ограничиваться только ей, а рассмотреть весь спектр энтропий Реньи. И с учётом полученных результатов, а также вычислительной сложности, выбрать оптимальное значение параметра энтропии Реньи.

Энтропия Реньи вычисляется по формуле:

$$ R_{\alpha} = \frac{1}{1-\alpha} \log\left( \sum_{i=1}^{n}p_i^{\alpha} \right), $$

где $p_i$ — вероятности, соответствующие распределению (в нашем случае — частоты чёрных и белых пикселей).

В случае $\alpha = 1$ это превращается в энтропию Шеннона:

$$ R_{1} = H = - \sum_{i=1}^{n} p_i \log(p_i) $$

Эксперимент

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

В таблице ниже представлены результаты для различных значений параметра энтропии Реньи $\alpha$:

Параметр энтропии Реньи $\alpha$	1/8	1/4	1/2	3/4	1	2	5
Среднее абсолютное отклонение	0.498	0.299	0.211	0.283	0.240	5.827	41.099
Доля полных совпадений (точность)	0.822	0.834	0.828	0.815	0.805	0.641	0.009
Доля совпадений с точностью до 1°	0.942	0.969	0.980	0.982	0.983	0.822	0.015
Доля совпадений с точностью до 2°	0.967	0.983	0.991	0.993	0.994	0.841	0.015

Всего было обработано 1665 документов.

Выводы из таблицы:

Наименьшее среднее абсолютное отклонение достигается при $\alpha = \frac{1}{2}$.
Наилучшая точность (доля полных совпадений) — при $\alpha = \frac{1}{4}$.
Наилучшая приемлемая точность (доля совпадений с точностью до 1° и до 2°) — при $\alpha \in {1, \frac{3}{4}, \frac{1}{2}}$.

Если рассматривать методику как часть комплекса оптического распознавания документов, то наилучшим значением оказывается $\alpha = \frac{1}{2}$.

При $\alpha = \frac{1}{2}$ среднее абсолютное отклонение составит всего $0.211^\circ$. При этом достигается оптимальная доля совпадений с точностью до 1°.

Есть ещё одна причина выбрать $\alpha = \frac{1}{2}$: при этом значении достигается оптимальная вычислительная сложность.

Ниже представлены результаты бенчмарка многократного вычисления энтропий для различных значений параметра $\alpha$:

$\alpha$	nanoseconds	miliseconds	% of Shannon
1	10249895206	10249	100
1/2	8677368472	8677	84.66
1/4	10421639934	10421	120.1
1/8	13235709810	13235	127
3/4	11403406522	11403	86.16
2	7245386547	7245	63.54
5	7771674801	7771	107.26
10	10809162384	10809	139.08

Из таблицы видно, что среди подходящих значений $\alpha$ наилучшая производительность достигается при $\alpha = 1/2$.

Алгоритм

Замечание:
Предлагаемый ниже алгоритм (исходный код на GitHub) предполагает, что для определения угла поворота мы используем бинарное чёрно-белое растровое изображение, в котором каждый пиксель может принимать два значения: 0 или 1.

Для применения алгоритма необходимо получить бинаризованную копию изображения.

Я реализовал алгоритм с применением библиотеки libleptonica (используется в TesseractOCR). Для этого использовал последовательное преобразование pixContrastTRC с contrast_factor = 1.0 и затем pixConvertTo1 с threshold = 170.

Пусть $h$ — высота, $w$ — ширина исходного изображения. Пусть $d = \sqrt{w^2 + h^2}$ — длина диагонали.

Будем поворачивать изображение на угол $\phi$ относительно центра изображения и считать среднюю энтропию по строкам и столбцам. Чтобы не выйти за границы, мысленно расширим полотно до размеров $d \times d$.

Определим:

$x_{from} = \frac{d}{2} - \frac{h |\sin(\phi)| + w |\cos(\phi)|}{2}$,
$x_{to} = d - x_{from}$,
$y_{from} = \frac{d}{2} - \frac{h |\cos(\phi)| + w |\sin(\phi)|}{2}$,
$y_{to} = d - y_{from}$

где $x_{from}$ и $x_{to}$ — границы по ширине, $y_{from}$ и $y_{to}$ — по высоте.

Нужно посчитать среднюю энтропию по строкам (и аналогично по столбцам).

Пусть $V(x, y)$ — цвет пикселя $(x, y)$ (0 или 1), $R({p, q})$ — энтропия распределения ${p, q}$.

Алгоритм расчёта средней энтропии $S_{\phi}$ для угла $\phi$ (по строкам):

S_phi = 0
for y in y_from .. y_to:
    b = 0  // количество чёрных пикселей в строке
    for x in x_from .. x_to:
        x_tilde = x - d/2
        y_tilde = y - d/2
        x' = x_tilde * cos(phi) - y_tilde * sin(phi) + w/2
        y' = x_tilde * sin(phi) + y_tilde * cos(phi) + h/2
        if x' >= 0 and x' < w and y' >= 0 and y' < h:
            b = b + V(x', y')
    p = b / d
    q = 1 - p
    S_phi = S_phi + R({p, q}) / d

Полученное значение $S_\phi$ — средняя энтропия для угла поворота $\phi$.

Для нахождения искомого угла поворота $\phi_0$ нужно найти минимум $S_\phi$:

$$ \phi_0 = -\arg\min_\phi S_\phi $$

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

Ссылки

Получение целочисленного типа по его длине

2019-09-12T12:00:00+03:00

Простой способ получить целочисленный тип по его длине

Пробуем контрактное программирование С++20 уже сейчас

2019-03-14T12:00:00+03:00

Пробуем контрактное программирование С++20 уже сейчас

В С++20 появилось контрактное программирование. На текущий момент ни один компилятор ещё не реализовал поддержку этой возможности.

Но есть способ уже сейчас попробовать использовать контракты из C++20, так как это описано в стандарте.

TL;DR

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

Про контрактное программирование уже написано много, но в двух словах расскажу что это такое и для чего нужно.

Логика Хоара

В основе парадигмы контрактов лежит логика Хоара (1, 2).

Логика Хоара – это способ формального доказательства корректности алгоритма. Она оперирует такими понятиями, как предусловие, постусловие и инвариант. С практической точки зрения, использование логики Хоара это, во-первых, способ формального доказательства корректности программы в тех случаях, когда ошибки могут привести к катастрофе или гибели людей. Во-вторых, способ повысить надёжность программы, наряду со статическим анализом и тестированием.

Контрактное программирование

(1, 2)

Основная идея контрактов в том, что по аналогии с контрактами в бизнесе, для каждой функции или метода описываются договорённости. Эти договорённости должны соблюдать как вызывающая сторона, так и вызываемая. Неотъемлемой частью контрактов является как минимум два режима сборки – отладочный и продуктовый. В зависимости от режима сборки контракты должны себя вести по разному. Наиболее распространённой практикой является проверка контрактов в отладочной сборке и их игнорирование в продуктовой.

Иногда в продуктовой сборке контракты тоже проверяются и их невыполнение может, например, вести к генерации исключения.

Основное отличие использования контрактов от «классического» подхода в том, что вызывающая сторона должна соблюдать предусловия вызываемой стороны, которые описываются в контракте, а вызываемая должна соблюдать свои постусловия и инварианты. Соответственно, вызываемая сторона не обязана проверять корректность передаваемых её параметров. Эта обязанность возлагается контрактом на вызывающую сторону.

Несоблюдение контрактов должно быть обнаружено на этапе тестирования и дополняет все виды тестов: модульные интеграционные и т. д.

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

Итак, какую пользу дают контракты:

Улучшают читаемость кода за счёт явного документирования.
Повышают надёжность кода, дополняя собой тестирование.
Позволяют компиляторам использовать низкоуровневые оптимизации и генерировать более быстрый код в расчёте на соблюдение контракта. В последнем случае несоблюдение контракта в релизной сборке может вести к UB.

Контрактное программирование в C++

Контрактное программирование реализовано во многих языках. Наиболее яркие примеры, это Eiffel, где парадигма была впервые реализована, и D, в D контракты являются частью языка.

В C++, до стандарта C++20, контракты можно было использовать в виде отдельных библиотек.

Такой подход имеет ряд недостатков:

Весьма неуклюжий синтаксис с использованием макросов.
Отсутствие единого стиля.
Невозможность использования контрактов компилятором для оптимизации кода.

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

Использование контрактов в таком виде, действительно делает код уродливым и нечитаемым. Это одна из причин, почему использование контрактов в C++ мало практикуется.

Забегая вперёд, покажу как в C++20 будет выглядеть использование контрактов. А затем, разберём всё это подробнее:

int f(int x, int y)
    [[ expects: x > 0 ]]       // precondition
    [[ expects: y > 0 ]]       // precondition
    [[ ensures r: r < x + y ]] // postcondition
{
    int z = (x - x%y) / y;
    [[ assert: z >= 0 ]];      // assertion
    return z + y;
}

Пробуем

К сожалению, на текущий момент ни один из широко используемых компиляторов ещё не реализовал поддержку контрактов. Но есть выход.

ARCOS research group из Universidad Carlos III de Madrid реализовали экспериментальную поддержку контрактов в форке clang++.

Чтобы не «писать код на бумажке», а иметь возможность сразу же попробовать новые возможности в деле, мы можем собрать этот форк и с его помощью пробовать приводимые ниже примеры.

Инструкция по сборке описана в readme репозитория на Гитхабе https://github.com/arcosuc3m/clang-contracts

git clone https://github.com/arcosuc3m/clang-contracts/
mkdir -p clang-contracts/build/ && cd clang-contracts/build/
cmake -G "Unix Makefiles" -DLLVM_USE_LINKER=gold -DBUILD_SHARED_LIBS=ON -DLLVM_USE_SPLIT_DWARF=ON  -DLLVM_OPTIMIZED_TABLEGEN=ON ../
make -j8

У меня не возникло проблем при сборке, но компиляция исходников занимает очень много времени.

Для компиляции примеров вам нужно будет явно указать путь к бинарнику clang++. Например, у меня это выглядит примерно так

/home/valmat/work/git/clang-contracts/build/bin/clang++ -std=c++2a -build-level=audit -g test.cpp -o test.bin

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

git clone https://github.com/valmat/cpp20-contracts-examples/
cd cpp20-contracts-examples
make CPP=/path/to/clang++

Здесь /path/to/clang++ путь к бинарнику clang++ вашей сборки экспериментального компилятора.

Кроме самого компилятора, ARCOS research group подготовили свою версию Compiler Explorer для своего форка.

Контрактное программирование в C++20

Теперь ничего не мешает нам приступить к исследованию возможностей, которые даёт контрактное программирование, и сразу пробовать эти возможности в деле.

Как уже было сказано выше, контракты строятся из предусловий, постусловий и инвариантов (утверждений).

В C++20 для этого используются атрибуты со следующим синтаксисом

[[contract-attribute modifier identifier: conditional-expression]]

Где contract-attribute может принимать одно из следующих значений: expects, ensures или assert.

expects используется для предусловий, ensures для постусловий и assert для утверждений.

conditional-expression – это булево выражение, проверяемый в контракте предикат. modifier и identifier могут быть опущены.

Зачем нужен modifier я напишу чуть ниже.

identifier используется только с ensures и служит для представления возвращаемого значения.

Предусловия имеют доступ к аргументам.

Постусловия имеют доступ к возвращаемому функцией значению. Для этого используется синтаксис

[[ensures return_variable: expr(return_variable)]]

Где return_variable любое валидное выражение для переменной.

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

Считается, что предусловия и постусловия являются частью интерфейса функции, в то время как утверждения являются частью её реализации.

Предикаты предусловий всегда вычисляются непосредственно перед выполнением функции. Постусловия выполняются сразу же после передачи функцией управления вызывающему коду.

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

Если при проверке выражения в контракте возникло ислючение, то будет вызван std::terminate().

Предусловия и постусловия всегда описываются вне тела функции и не могут иметь доступ к локальным переменным.

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

Утверждения (инварианты) всегда описываются в теле функции или метода. По дизайну они являются частью реализации. И, соответственно, могут иметь доступ ко всем доступным данным. В том числе, к локальным переменным функции и приватным и защищённым полям класса.

пример 1

Определим два предусловия, одно постусловие и один инвариант:

int foo(int x, int y)
    [[ expects: x > y ]]   // precondition  #1
    [[ expects: y > 0 ]]   // precondition  #2
    [[ ensures r: r < x ]] // postcondition #3
{
    int z = (x - x%y) / y;
    [[ assert: z >= 0 ]];  // assertion
    return z;
}

int main()
{
    std::cout << foo(117, 20) << std::endl;
    std::cout << foo(10,  20) << std::endl; // <-- contract violation #1
    std::cout << foo(100, -5) << std::endl; // <-- contract violation #2

    return 0;
}

пример 2

Предусловие публичного метода не может ссылаться на защищённое или приватное поле:

struct X
{
//protected:
    int m = 5;
public:
    int foo(int n)
        [[expects: n < m]]
    {
        return n*n;
    }
};

Не допускается модификация переменных внутри выражений, описываемых атрибутами контракта. Если это нарушено, будет UB.

Выражения, описываемые в контрактах, не должны иметь побочных эффектов. Хотя компиляторы могот это проверять, такая обязанность на них не возлагается. Нарушение этого требования считается неопределённым поведением.

struct X
{
    int m = 5;
    int foo(int n)
        [[ expects: n < m++ ]]  // UB: Modifies variable m
    {
        int k = n*n;
        [[ assert: ++k < 100 ]] // UB: Modifies variable k
        return n*n;
    }
};

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

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

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

Это означает, что в первую очередь всегда проверяются предусловия, как проиллюстрировано в следующем примере:

int foo(int n)
    [[ expects:   expr(n) ]] // # 1
    [[ ensures r: expr(r) ]] // # 4
    [[ expects:   expr(n) ]] // # 2
    [[ expects:   expr(n) ]] // # 3
    [[ ensures r: expr(r) ]] // # 5
{...}

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

int foo(int &n) [[ ensures: expr(r) ]];

В этом случае можно опустить идентификатор возвращаемого значения.

Если постусловие ссылается на аргумент функции, то этот аргумент рассматривается в точке выхода из функции, а не в точке входа, как в случае с предусловиями.

Нет никакого способа ссылаться на оригинальное (в точке входа в функцию) значение в постусловии.

пример:

void incr(int &n)
    [[ expects: 3 == n ]]
    [[ ensures: 4 == n ]]
{++n;}

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

Например, для constexpr функции нельзя ссылаться на локальные переменные, если только они не известны во время компиляции.

пример:

int a = 1;
constexpr int b = 100;

constexpr int foo(int n)
  [[ expects: a <= n ]] // error: `a` is not constexpr
  [[ expects: n <  b ]] // OK
{
  [[assert: n > 2*a]];  // error: `a` is not constexpr
  [[assert: n < 2*b]];  // OK
  return 2*n;
}

Контракты для указателей на функцию

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

пример:

int foo(int n)
    [[expects: n < 10]]
{
    return n*n;
}

int (*pfoo)(int n) = &foo;

Вызов pfoo(100) приведёт к нарушению контракта.

Контракты при наследовании

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

В реализации C++20 это не так.

Во-первых, инварианты в C++20 являются частью реализации, а не интерфейса. По этой причине, их можно как усилить, так и ослабить. Если в реализации виртуальной функции assert отсутствует, то он не будет унаследован.

Во-вторых, требуется, чтобы при наследовании функции были ODR идентичны. А, поскольку предусловия и постусловия являются частью интерфейса, то в наследнике они должны в точности совпадать.

При этом, описание предусловий и постусловий при наследовании можно опустить. Но если они объявлены, то должны в точности совпадать с определением в базовом классе.

пример:

struct Base
{
    virtual int foo(int n)
        [[ expects:   n < 10  ]]
        [[ ensures r: r > 100 ]]
    {
        return n*n;
    }
};

struct Derived1 : Base
{
    virtual int foo(int n) override
        [[ expects:   n < 10  ]]
        [[ ensures r: r > 100 ]]
    {
        return n*n*2;
    }
};

struct Derived2 : Base
{
    // Inherits contracts from Base
    virtual int foo(int n) override
    {
        return n*3;
    }
};

<spoiler title="Замечание">

К сожалению, пример выше не работает в экспериментальном компиляторе как ожидается.

Если у foo из Derived2 опустить контракт, то он не будет унаследован из базового класса. Кроме того, компилятор позволяет определить для подкласса контракт несовпадающий с контрактом базового.

Ещё одна ошибка экспериментального компилятора: синтаксически правильной должна быть запись

virtual int foo(int n) override
    [[expects: n < 10]]
{...}

Однако в таком виде я получил ошибку компиляции

inheritance1.cpp:20:36: error: expected ';' at end of declaration list
    virtual int foo(int n) override
                                   ^
                                   ;

и пришлось заменить на

virtual int foo(int n)
    [[expects: n < 10]]
override
{...}

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

</spoiler>

Модификаторы контрактов

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

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

default – этот модификатор используется по умолчанию. Предполагается, что вычислительная стоимость проверки выполнения выражения с этим модификатором небольшая, по сравнению со стоимостью вычисления самой функции.
audit – этот модификатор предполагает, что вычислительная стоимость проверки выполнения выражения значительна по сравнению со стоимостью вычисления самой функции.
axiom – этот модификатор используется, если выражение носит декларативный характер. Не проверяется во время выполнения. Служит для документирования интерфейса функции, использования статическими анализаторами и оптимизатором компилятора. Выражения с модификатором axiom никогда не вычисляются во время выполнения.

Пример

[[expects: expr]]         // Неявно default
[[expects default: expr]] // Явно default
[[expects axiom  : expr]] // Run-time проверки не выполняются
[[expects audit  : expr]] // Вычислительно дорогая проверка

Используя модификаторы, можно определить какие проверки в каких версиях ваших сборок будут использоваться, а какие будут отключены.

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

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

В нашем случае, это опция компилятора

-axiom-mode=<mode>

-axiom-mode=on включает режим аксиом и, соответственно, выключает проверку утверждений с идентификатором axiom,

-axiom-mode=off выключает режим аксиом и, соответственно, включает проверку утверждений с идентификатором axiom.

пример:

int foo(int n)
    [[expects axiom: n < 10]]
{
    return n*n;
}

Программа может быть скомпилирована с тремя разными уровнями проверки:

off выключает все проверки выражений в контрактах
default проверяются только выражения с модификатором default
audit расширенный режим, когда выполняются все проверки с модификатором default и audit

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

В нашем случае, для этого используется опция компилятора

-build-level=<off|default|audit>

По умолчанию используется -build-level=default

Как уже было сказано, компилятор может использовать контракты для низкоуровневых оптимизаций. По этой причине, не смотря на то, что во время выполнения некоторые предикаты в контрактах (в зависимости от уровня проверки) могут не вычисляться, их невыполнение ведёт к неопределённому поведению.

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

Перехват нарушения контракта

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

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

При компиляции можно установить обработчик violation handler, вызываемый при нарушении контракта.

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

В нашем случае это

-contract-violation-handler=<violation_handler>

Сигнатура обработчика должна иметь вид

void(const std::contract_violation& info)

или

void(const std::contract_violation& info) noexcept

std::contract_violation эквивалентна следующему определению:

struct contract_violation
{
    uint_least32_t   line_number()     const noexcept;
    std::string_view file_name()       const noexcept;
    std::string_view function_name()   const noexcept;
    std::string_view comment()         const noexcept;
    std::string_view assertion_level() const noexcept;
};

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

Если обработчик violation handler задан, то, в случае нарушения контракта, по умолчанию, сразу после его выполнения будет вызван std::abort() (Без указания обработчика вызывается std::terminate()).

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

Способ реализации этих средств остаётся на усмотрение разработчиков компилятора. В нашем случае, это опция компилятора

-fcontinue-after-violation

Опции -fcontinue-after-violation и -contract-violation-handler могут быть установлены независимо друг от друга. Например, можно установить -fcontinue-after-violation, но не устанавливать -contract-violation-handler. В последнем случае, после нарушения контракта программа просто продолжит работу.

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

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

Это связано с возможностью компилятора выполнять низкоуровневые оптимизации в рассчёте на выполнение конрактов.

В идеале, если произошло нарушение конракта, нужно как можно скорее записать диагностическую информацию и завершить работу программы. Нужно точно понимать, что вы делаете позволяя программе работать после violation.

Определим свой обработчик и с его помощью перехватим нарушение конракта

void violation_handler(const std::contract_violation& info)
{
    std::cerr << "line_number     : " << info.line_number()     << std::endl;
    std::cerr << "file_name       : " << info.file_name()       << std::endl;
    std::cerr << "function_name   : " << info.function_name()   << std::endl;
    std::cerr << "comment         : " << info.comment()         << std::endl;
    std::cerr << "assertion_level : " << info.assertion_level() << std::endl;
}

И рассмотрим пример нарушения конракта:

#include "violation_handler.h"

int foo(int n)
    [[expects: n < 10]]
{
    return n*n;
}

int main()
{
    foo(100); // <-- contract violation
    return 0;
}

Скомпилируем программу с опциями -contract-violation-handler=violation_handler и -fcontinue-after-violation и запустим

$ bin/example8-handling.bin
line_number     : 4
file_name       : example8-handling.cpp
function_name   : foo
comment         : n < 10
assertion_level : default

Теперь можно привести примеры, демонстрирующие поведение программы при нарушении контракта при разных уровнях сборки и режимах контрактов.

Рассмотрим следующий пример:

#include "violation_handler.h"

int foo(int n)
    [[ expects axiom   : n < 100 ]]
    [[ expects default : n < 200 ]]
    [[ expects audit   : n < 300 ]]
{
    return 2 * n;
}

int main()
{
    foo(350); // audit
    foo(250); // default

    return 0;
}

Если собрать его с опцией -build-level=off то как и ожидается, конракты не будут проверяться.

Собрав с уровнем default (с опцией -build-level=default), получим следующий вывод:

$ bin/example9-default.bin
line_number     : 5
file_name       : example9.cpp
function_name   : foo
comment         : n < 200
assertion_level : default

line_number     : 5
file_name       : example9.cpp
function_name   : foo
comment         : n < 200
assertion_level : default

И сборка с уровнем audit даст:

 $ bin/example9-audit.bin
line_number     : 5
file_name       : example9.cpp
function_name   : foo
comment         : n < 200
assertion_level : default

line_number     : 6
file_name       : example9.cpp
function_name   : foo
comment         : n < 300
assertion_level : audit

line_number     : 5
file_name       : example9.cpp
function_name   : foo
comment         : n < 200
assertion_level : default

Замечания

violation_handler может бросать исключения. В этом случае можно настроить программу так, чтобы нарушение контракта вело к выбросу исключения.

Если функция, у которой описаны контракты, помечена как noexcept и при проверке контракта вызван violation_handler, который бросает исключение, то будет вызван std::terminate().

Пример

void violation_handler(const std::contract_violation&)
{
    throw std::exception();
}

int foo(int n) noexcept
    [[ expects: n  > 0 ]]
{
    return n*n;
}

int main()
{
    foo(0); // <-- std::terminate() when violation handler throws an exception
    return 0;
}

Если компилятору передан флаг: не продолжать выполнение программы после нарушения контракта (continuation mode=off), но обработчик violation handler бросает исключение, то будет принудительно вызвана std::terminate().

Заключение

Контракты относятся к неинтрузивным проверкам времени выполнения. Они играют очень важную роль в обеспечении качества выпускаемого программного обеспечения.

C++ используется очень широко. И наверняка найдётся достаточное количество притензий к спецификации контрактов. На мой субъективный взгляд, реализация получилась довольно удобной и наглядной.

Контракты C++20 позволят сделать наши программы ещё более надёжными, быстрыми и понятными. С нетерпением жду их реализацию в компиляторах.

Ссылки

Gist
Habr

Установка сертификатов LetsEncript

2018-05-20T12:00:00+03:00

Установка сертификатов LetsEncript

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

Описание установки тут:

Установка пакетов:

apt-get install software-properties-common
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install certbot python-certbot-nginx

Затем можно устанавливать сертификат Что бы получить список опций certbot набираем certbot –help

certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Установка тодлко сертификата без правок конфига:

certbot --nginx certonly

При создании сертификата можно указать домены:

certbot --nginx certonly  -d avtogs.ru -d www.avtogs.ru -d msk.avtogs.ru

Если набрать certbot --nginx То certbot попытается в конец конфига дописать включение сертификата

Проверка обновления:

certbot renew --dry-run

Ручное обновление:

certbot renew

Ручное обновление с перезапуском конфигов:

certbot -q renew --post-hook "service nginx reload"
certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"
certbot renew -a nginx --cert-name /etc/letsencrypt/renewal/my-domain.org

посмотреть сертификаты

certbot certificates

Проверим полученный сертификат

openssl x509 -text -in /etc/letsencrypt/live/avtogs.ru/cert.pem

После установки можно попдправить Cron скрипт в /etc/cron.d ( /etc/cron.d/certbot )

22 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew --post-hook "service nginx reload"

Что бы сертификаты заработали в конфиг Nginx нужно добваить

server {
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/biotrapeza.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/biotrapeza.ru/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ...
}
server {
    listen  80;
    server_name  plazan.ru en.plazan.ru www.plazan.ru;
    return 301 https://$host$request_uri;
}

–

См ещё: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

Источник

Proxy для Telegram

2018-04-14T12:00:00+03:00

В связи с попытками блокировок Telegram

Проверено на 5 баксовом тарифе DigitalOcean

Создаём proxy пользователя для аутентификации по паролю:

useradd -d /dev/null teleg
passwd teleg

Сразу же закрываем этому пользователю вход по SSH: (ещё лучше всегда менять ssh порт с дефолтного на кастомный)

nano /etc/ssh/sshd_config

#Port 22
Port 4251

Match User teleg
PasswordAuthentication no
Match all

Рестартим ssh:

/etc/init.d/ssh restart

Проверяем:

ssh -p4251 teleg@<ip>

Должно быть

Permission denied (publickey).

В репах Убунту старый и глючный dante-server Поэтому берём свежий пакет

cd /tmp
wget http://ppa.launchpad.net/dajhorn/dante/ubuntu/pool/main/d/dante/dante-server_1.4.1-1_amd64.deb
dpkg -i dante-server_1.4.1-1_amd64.deb
rm dante-server_1.4.1-1_amd64.deb

Редактируем настройки Данте-сервера:

cp /etc/danted.conf  /etc/danted~.conf
nano /etc/danted.conf

Конфиг:

logoutput: syslog /var/log/danted.log
user.privileged: root
user.unprivileged: teleg

# The listening network interface or address.
internal: 0.0.0.0 port=1180

# The proxying network interface or address.
external: eth0

# socks-rules determine what is proxied through the external interface.
# The default of "none" permits anonymous access.
socksmethod: username

# client-rules determine who can connect to the internal interface.
# The default of "none" permits anonymous access.
clientmethod: none

client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect disconnect error
}

socks pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect disconnect error
}

Здесь user.unprivileged: teleg – имя пользователя, которого мы создали выше port=1180 мржете указать сами. Номер должен быть больше 1000

Сетевой интерфейс: external: eth0 Имя сетевого интерфейса может отличаться. Обычно eth0 Что бы посмотреть имя используемого сетевого интерфейса нужно набрать

ifconfig

Перезапускаем dante-server:

/etc/init.d/danted stop
/etc/init.d/danted start

Проверяем работает ли proxy:

curl -v -x socks5://teleg:<psw>@<ip>:<port> http://ya.ru/

, и нужно указать свои

Если всё нормально, то Ok Ссылка для включения прокси в телеграме:

https://t.me/socks?server=<ip>&port=<port>&user=teleg&pass=<psw>

Если что-то пошло не так, то смотрим логи:

cat /var/log/danted.log

Инструкцию эту собрал сам из разных источников. Лично мной проверена.

Источник

CRTP и двойной статическая полиморфизм C++

2018-03-27T12:00:00+03:00

CRTP и двойной статическая полиморфизм

Ниже представлен паттерн проектирования на C++, известный как CRTP (Curiously Recurring Template Pattern).

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

Зачем нужен этот код?

Обычный полиморфизм в C++ реализуется через виртуальные функции и наследование, что приводит к использованию виртуальной таблицы (vtable) и некоторым накладным расходам. Однако иногда нам требуется полиморфизм без этих издержек, особенно если все типы известны на этапе компиляции. Здесь на помощь приходит CRTP — паттерн, при котором класс-наследник передаёт себя как параметр шаблона базовому классу.

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

Что делает этот код?

WordGetterBase — базовый шаблонный класс, реализующий интерфейс для получения строки (getWord()) и вывода её в консоль (printWord()). Реализация метода getWord() делегируется классу-наследнику через CRTP.
WordGetterW1 и WordGetterW2 — конкретные реализации, возвращающие разные строки.
StrPrinterBase — ещё один шаблонный базовый класс, который наследуется от конкретного WordGetter и расширяет интерфейс методом printStr(). Он также использует CRTP для вызова метода наследника.
StrPrinter1 и StrPrinter2 — конкретные реализации принтера, которые форматируют и выводят строку, полученную от соответствующего WordGetter.
В функции main демонстрируется использование этих классов: выводятся строки напрямую через WordGetter’ы и с помощью различных StrPrinter’ов.

Haskell

2016-11-14T12:49:58+03:00

Мои эксперементы с Haskell

Сделал тоже самое что описано в посте про C++

Haskell – классный язык программирования. Но писатьна нём что то в одиночку очень тяжело.

Мой первый Arduino проект

2016-02-21T15:35:00+00:00

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

Решил попробовать сделать необходимый девайс на Arduino.

До этого с микроконтроллерами дела не имел. Оказалось, это совсем не сложно и даже интересно.

Исходники выложил на GitHub: https://github.com/valmat/BatterySensor

Документация там же.

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

На корпусе расположил выключатель и кнопку. Кнопка выключает светодиоды, а долгое нажатие кнопки отключает подсветку экрана. Для экономии батареи в солнечный день и чтобы не слепило ночью.

Кроме того, подключил датчик BMP180. Устройство показывает температуру и давление. Давление на рыбалке знать необходимо.

Корпус сделал герметичным. Всё проклеил резиновым клеем, а сверху заклеил алюминиевым скотчем.

Работает надёжно. Показания точные.

Определение по списку в C++

2014-11-18T16:38:00+00:00

В PHP есть возможность присвоить переменным значения, используя массив:

list($a, $b) = array('str1', 'str2');

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

a, b = ['str1', 'str2']

А вот в C++ такой языковой конструкции нет. Но это совершенно не проблема, потому что ее можно сделать самому.

Вот что у меня получилось:

См также Optimized string concatenation: strjoin.cpp

Нужен C++11, т.к. используются Ref-qualifiers.

P.S. blogger.com как всегда портит код. Надо менять блогодвижок.

Микро-бенчмарк RocksDB server

2014-08-21T06:00:00+00:00

В полноценном смысле то, что я тут хочу написать, конечно, бенчмарком не является. Но вполне способно дать понимание области применения RocksDB.

RocksDB — это довольно крутое хранилище, являющееся (на данный момент) встраиваемым решением. Главной фишкой RocksDB является то, что она рассчитана на использование на flash-накопителях, то есть на SSD-дисках.

Лично я давно ждал появления таких решений. Поскольку память всё ещё дорогая, а жёсткие диски медленные, использование SSD для хранения данных — очень логичный шаг.

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

Поэтому я написал собственную серверную обёртку: https://github.com/valmat/RocksServer. В настоящее время она вполне функциональна, протестирована и готова к работе. Но есть ещё моменты, требующие улучшения. Эти моменты никак не связаны с её пригодностью к использованию, поэтому ничто не мешает уже сейчас произвести замеры производительности.

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

Итак, табличка.

MultiGet со случайными ключами.

Условия проведения эксперимента:

В базе данных 1 000 000 ключей.
Выбирается набор случайных ключей в случайном порядке.
Кэш не используется. Прямо перед экспериментом я перезагрузил компьютер, чтобы полностью исключить возможность использования файлового кэша.
Хранимые значения имеют длину 50 ±5 байт.

Количество ключей в выборке	SSD	HDD
50	4.7 ms	131.3 ms
300	12.6 ms	2371.4 ms (~2s)
1000	29.5 ms	7918.4 ms (~8s)
10 000	124.6 ms	45229.5 ms (~45s)
100 000	2346.6 ms	51855.8 ms (~56s)

Следует отметить, что после попадания ключей в кэш скорость выборки на HDD возрастает и приближается к скорости выборки на SSD.

Какие выводы можно сделать из таблички? RocksDB действительно очень быстрое хранилище и подходит для использования на SSD-дисках.

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

Clang vs gcc performance

2014-05-31T21:18:00+00:00

Стало мне интересно, и решил я провести такую глупую проверку: сравнить производительность программ, откомпилированных Clang’ом и gcc.

Для эксперимента взял первую попавшуюся реализацию пузырьковой сортировки с GitHub’а.

Компилировал с опциями -g, -O1, -O2, -O3 и без опций.

Получилось интересно и неожиданно.

Для запуска тестов использовал такой скрипт:

#!/bin/bash

OPT="-O3"
g++ $OPT bubble.cpp -o bubble1
clang++ $OPT bubble.cpp -o bubble2   # -stdlib=libstdc++
clang++ $OPT -stdlib=libc++ bubble.cpp -o bubble3 # -stdlib=libc++

# ls -slh
# exit;

sleep 3
time ./bubble1 > /dev/null
sleep 3
time ./bubble2 > /dev/null
sleep 3
time ./bubble3 > /dev/null

Меняя параметр OPT.

Поясню, что здесь компилируется:

g++ $OPT bubble.cpp -o bubble1
Используется gcc
clang++ $OPT bubble.cpp -o bubble2
Используется clang со стандартной библиотекой libstdc++ от gcc
clang++ $OPT -stdlib=libc++ bubble.cpp -o bubble3
Используется clang со своей собственной стандартной библиотекой libc++

Результаты производительности

Опция	gcc	clang -stdlib=libstdc++ (gcc)	clang -stdlib=libc++
-g	real 0m3.337s user 0m3.335s sys 0m0.004s	real 0m3.294s user 0m3.296s sys 0m0.000s	real 0m3.323s user 0m3.325s sys 0m0.000s
без опций	real 0m3.334s user 0m3.336s sys 0m0.000s	real 0m3.293s user 0m3.295s sys 0m0.000s	real 0m3.320s user 0m3.318s sys 0m0.004s
-O1	real 0m1.735s user 0m1.735s sys 0m0.000s	real 0m1.485s user 0m1.486s sys 0m0.000s	real 0m1.493s user 0m1.494s sys 0m0.000s
-O2	real 0m1.516s user 0m1.517s sys 0m0.000s	real 0m1.522s user 0m1.523s sys 0m0.000s	real 0m1.495s user 0m1.492s sys 0m0.004s
-O3	real 0m1.510s user 0m1.506s sys 0m0.004s	real 0m1.534s user 0m1.535s sys 0m0.000s	real 0m1.498s user 0m1.499s sys 0m0.000s

Размеры бинарников

Опция	gcc	clang -stdlib=libstdc++ (gcc)	clang -stdlib=libc++
-g	22K	28K	65K
без опций	9,2K	8,3K	15K
-O1	8,9K	8,4K	12K
-O2	8,9K	8,1K	12K
-O3	8,9K	8,1K	12K

Понятно, что по такому примеру корректно сравнивать компиляторы нельзя, но для меня, как для приверженца GNU компилятора, результаты получились неожиданными.

По сути, clang превзошёл gcc во всех направлениях.

Для меня основной вывод такой:
Clang заслуживает внимания и заслуживает того, чтобы к нему присмотреться. Тем более, сообщения об ошибках, которые он выдаёт, информативнее, чем сообщения, выдаваемые gcc.

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

Мои версии clang и gcc:

gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
Debian clang version 3.2-7ubuntu1 (tags/RELEASE_32/final) (based on LLVM 3.2)

Отчетность в налоговую на Linux

2014-03-20T10:43:00+00:00

Как я готовлю отчетность в налоговую.

Выписки у меня достаются в таком формате:

2014.01.20.rtf
2014.01.20-1.rtf
…

В первую очередь, нужно упорядочить по дате, поэтому переименовываем:

for i in `find . -type f -name "*.rtf*"`; do
  dst=`echo $i | sed -e :a -e 's/\(.*\)\([0-9]\{2\}\)\.\([0-9]\{2\}\)\.\([0-9]\{4\}\)\(.*\)/\1\4.\3.\2\5/;ta'`
  echo mv $i $dst
done

Потом конвертируем в PDF:

libreoffice --invisible --convert-to pdf *.rtf

И соединяем все в один файл:

gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=toprint.pdf -dBATCH `find . -type f -name "*.pdf" | sort`

Всё.

Документация PHP-CPP

2014-03-10T18:42:00+00:00

У PHP-CPP появился раздел с документацией.

Вообще разработка библиотеки идет семимильными шагами, и, похоже, недолго осталось ждать первого рабочего релиза. Когда будет готово, напишу подробнее про саму библиотеку и её возможности.

PS: Вместо того чтобы что-то писать здесь про библиотеку, я просто взял и начал переводить документацию на русский язык: http://phpcpp.ru/

Основная цель этого перевода — познакомить русскоязычное сообщество с библиотекой.

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

Сравнение производительности C++ php-расширения с нативным кодом

2014-01-12T15:11:00+00:00

Давно меня интересовал вопрос: насколько увеличивается производительность при переписывании нативного кода в php-расширение.

И вот я решил провести сравнение.

В качестве платформы для написания расширения была выбрана библиотека PHP-CPP.

Пару слов о самой библиотеке PHP-CPP.
Довольно неплохая библиотека. Работать с ней приятно и удобно. Честно говоря, никогда еще не было так легко писать расширения для php.
Из минусов могу отметить недостаток документации. Чтобы разобраться с некоторыми вещами, недостаточно даже примеров, которыми автор снабжает код — приходится смотреть исходники. В частности, я так и не разобрался, как перенести статический метод класса из C++ в статический же метод в php.
Основана она на C++11, т.е. на старых дистрибутивах может потребоваться обновить gcc.

В качестве подопытного был выбран модуль постраничного разбиения.
Исходники на GitHub: https://github.com/valmat/myscrnav
Я написал два идентичных класса: один на php, другой на C++ (в виде расширения к php).

Пару слов как пользоваться.
Пример использования есть в исходниках: https://github.com/valmat/myscrnav/blob/master/screennav_test.php

Создаем pagination-объект из расширения:

$scr = new myScrNav($pageNom, $Count, '/url/to/page/');

Или из php-класса:

require 'php/class.screennav.php';
$scr = new ScreenNav($pageNom, $Count, '/url/to/page/');

Задаём необходимые параметры (если необходимо, можно не задавать):

$scr->setInterval(10);       // Сколько объектов на странице
$scr->setPrefix('?qwe&part='); // URL prefix
$scr->setPostfix('&prm=132');  // URL postfix
$scr->setSpace('<space>...</space>'); // Разделитель блоков табов
$scr->setCssName('newClassName');     // Имя класса css блока управления постраничным выводом
$scr->setMidTab(15);          // см. info.png
$scr->setMaxTab(5);           // см. info.png
$scr->showCount(true);        // Показывать ли общее количество элементов

Кроме того, доступны следующие методы для получения вычисленных данных:

getStartPos();   // Номер начального элемента на текущей странице (для выборки из БД)
getLimitPos();   // Длина списка элементов на странице на текущей странице (для выборки из БД)
getPageCnt();    // Количество страниц при разбивке на части
getStartPos();   // Номер (вычисленный) текущей страницы
show();          // Возвращает собственно сам элемент управления постраничной разбивкой (html)

То есть можно управлять постраничной разбивкой и делать запросы к БД на основе этой разбивки. Внешний вид, разумеется, полностью настраивается через css.

Теперь сами результаты сравнения.
PHP тестируется с включённым опкешером (apc). Без него смысла тестировать не вижу, ибо тестировать нужно так, как используется на рабочей системе.

1
Во-первых, сравним просто функции.

На php будет:

function ScreenNav_pageNo($var) {
    return (isset($_GET[$var])) ? ((int)$_GET[$var] - 1) : 0;
}

На C++:

Php::Value GETpageNom(Php::Parameters &params) {
    if (params.size() == 0) return 0;
    string var = (new Php::Value(params[0]))->stringValue();
    string get = Php::globals["_GET"][var];
    long int rez = (new Php::Value(get))->numericValue();
    return rez ? (rez - 1) : 0;
}

php

memory usage: 0.56Kb
memory peak_usage: 1.1Kb
Вычисленное: time: 50·10⁻⁶ sec
ab -n 10000 … : Time per request: 0.39 [ms] (mean)

C++

memory usage: 1.26Kb
memory peak_usage: 1.8Kb
Вычисленное: time: 60·10⁻⁶ sec
ab -n 10000 … : Time per request: 0.4 [ms] (mean)

Как видно, на таком простом примере расширение не выигрывает, а даже проигрывает нативному коду.

2
Теперь сравним классы.

php

time: 215·10⁻⁶ sec
memory usage: 16.5Kb
memory peak_usage: 22.7Kb
ab -n 10000 … : Time per request: 0.533 [ms] (mean)

C++

time: 170·10⁻⁶ sec
memory usage: 2.3Kb
memory peak_usage: 4.6Kb
ab -n 10000 … : Time per request: 0.49 [ms] (mean)

Выводы

Разница во времени порядка 10⁻⁵ sec — не то, ради чего нужно переписывать с php на C++.
С другой стороны, само то, что она проявилась на такой незначительной задаче — уже результат.
Приведённый пример позволяет понять порядок выигрыша и оценить целесообразность переписывания нативного кода в C++ расширение.

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

Сериализация в PHP

2013-12-15T19:08:00+00:00

Будут сравниваться 4 способа сериализации:

Стандартная сериализация serialize
JSON
msgpack
igbinary

Кратко об установке

JSON раньше шел в стандартной поставке PHP. Сейчас нужно поставить дополнительное расширение php5-json.

msgpack
Сайт: http://msgpack.org/
Исходники: github.com/msgpack/msgpack-php и http://pecl.php.net/package/msgpack
Ставим:

cd /tmp
wget http://pecl.php.net/get/msgpack-0.5.5.tgz
tar xzf msgpack-0.5.5.tgz
cd msgpack-0.5.5
phpize
./configure
make
make test

Если тесты прошли нормально, то создаем пакет и ставим:

sudo checkinstall -D --install=no
sudo dpkg -i msgpack_0.5.5-1_amd64.deb

igbinary
Исходники: github.com/phadej/igbinary и http://pecl.php.net/package/igbinary
Далее опять:

cd /tmp
wget http://pecl.php.net/get/igbinary-1.1.1.tgz
tar xzf igbinary-1.1.1.tgz
cd igbinary-1.1.1
phpize
./configure
make
make test
sudo checkinstall -D --install=no
sudo dpkg -i igbinary_1.1.1-1_amd64.deb

msgpack добавляет функции:

BinData msgpack_pack(phpValue);
phpValue msgpack_unpack(BinData);

igbinary добавляет функции:

BinData igbinary_serialize(phpValue);
phpValue igbinary_unserialize($BinData);

Чтобы они заработали, нужно не забыть включить их в php.ini:

[igbinary]
extension=igbinary.so

; Enable or disable compacting of duplicate strings
; The default is On.
;igbinary.compact_strings=On

[msgpack]
extension=msgpack.so

Что еще важно отметить

serialize — стандартная функция PHP.
JSON — старое и стабильное расширение.
igbinary — тоже достаточно старая библиотека, давно вышедшая в стабильную ветку.
msgpack — на данный момент все еще находится в стадии beta. С msgpack мне реально доводилось ловить глюки в ее предыдущих релизах. И если я решусь внедрять ее в продакшен, то только там, где ее ошибки не принесут фатального ущерба.

Тесты

1. Массив ассоциативный: вложенные массивы и строки

array (
  'v0' => 
    array (
      0 => 0,
      1 => 1,
      2 => 2,
      ...
      3 => 3,
      23 => 23,
      24 => 24,
    ),
  'rnd0' => '2e0c883df6e2cb771103f4409f053549094d6787',
  ...
)

c 16384 элементами

	Время сериализации (msec)	Время десериализации (msec)	Размер упакованных данных (Kb)
MessagePack	9	25	678
igbinary compact_strings=Off	9	32	1278
igbinary compact_strings=On	16	32	1120
JSON	14	318	1022
SERIALIZE	62	39	2486

2. Массив числовой: большие массивы целых чисел

array (
  0 => 3183,
  1 => 4527,
  2 => 4084,
  3 => 4032,
  4 => 3920,
  ...
  262144 => 4455,
)

	Время сериализации (msec)	Время десериализации (msec)	Размер упакованных данных (Kb)
MessagePack	8	30	769
igbinary compact_strings=Off	9	33	1920
igbinary compact_strings=On	9	33	1920
JSON	15	107	1281
SERIALIZE	86	44	3988

3. Массив числовой: большие массивы длинных целых чисел (int64)

array (
  0 => 7679461759223599104,
  1 => 4898705982311625344,
  2 => 5880628818820227328,
  ...
  262144 => 6940876209816891904,
)

	Время сериализации (msec)	Время десериализации (msec)	Размер упакованных данных (Kb)
MessagePack	10	29	2305
igbinary compact_strings=Off	11	33	3456
igbinary compact_strings=On	11	33	3456
JSON	20	172	5121
SERIALIZE	92	49	7828

4. Массив числовой: большие массивы чисел с плавающей точкой (float)

array (
  0 => 0.00038631346578366,
  1 => 0.00016131634134538,
  2 => 0.00043595779928503,
  3 => 0.00011754334410814,
  4 => 0.00049353469548909,
  5 => 5.2391680201184E-5,
  ...
  262144 => 0.00041876046901173,
)

	Время сериализации (msec)	Время десериализации (msec)	Размер упакованных данных (Kb)
MessagePack	9	28	2305
igbinary compact_strings=Off	11	33	3456
igbinary compact_strings=On	11	33	3456
JSON	75	197	5061
SERIALIZE	264	176	8538

5. Массив строковый: большие массивы длинных строк

array (
  0 => 'f7df8cb47630b8cd7eb73d0da7a23b9c01aaaa84f718499c1c8cef6730f9fd03c8125cab',
  1 => 'd30f79cf7fef47bd7a5611719f936539bec0d2e93bcf6eecb2611212e088d0d91f2ade9c',
  2 => '86bce22a4d2805649853ac7909c4efb4dd18f255086af6e4641abb18caafc151b9aa95c8',
  3 => '63afd0edc0371ad842d7a7ecc76260be4bc3e8c0da6cb383f8f9e58f2c8af88a8c0eb65e',
  4 => '13c80015875a668e8fc059517ffd124abbda63c12d95666e2649fcfc6e3af75e09f5adb9',
  ...
  32768 => '0e3808238b738aafc13a2a62f36d2a49dec4e191c22abfa379f38b5b0411bc11fa9bf92f',
)

	Время сериализации (msec)	Время десериализации (msec)	Размер упакованных данных (Kb)
MessagePack	4	5	2401
igbinary compact_strings=Off	4	6	2464
igbinary compact_strings=On	21	6	2463
JSON	28	16	2401
SERIALIZE	10	7	2806

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

Разжился SSD диском

2013-12-02T11:55:00+00:00

Вот и я разжился SSD диском.

Будет на чем тестить NoSQL SSD хранилища.

В планах потестить на нем RocksDB, LevelDB и, возможно, RethinkDB.

Пластилиновый мультик

2013-03-04T08:50:00+00:00

Сделали с дочей мультик из пластилина.

Делается так:

convert -delay 20 -loop 0 *.jpg mygif.gif

Вот результат:

Еще полезное:

Сделать из кадров ролик:

convert -delay 20 -loop 0 *.jpg mympg.mpg

MOV из gif:

convert mygif.gif mymov.mov

Видео на YouTube:

Смотреть на YouTube

Топ 7 ботов за сутки

2013-03-01T09:32:00+00:00

По результатам выборки из логов сервера за 1 сутки.

Googlebot — 43 229 запросов
YandexDirect — 21 260
Mediapartners-Google — 14 386
Mail.RU_Bot — 13 715
YandexBot — 13 079
AhrefsBot — 11 997
openstat ru/Bot — 2 709

Выводы:
Гугл предсказуемо обошёл всех и вся. Честь и хвала ему.
Удивил Mail.RU, который обошёл Яндекс.
Что касается Яндекса, то очевидно, что приоритет Яндекса — их рекламная сеть. И уже потом поисковые технологии.

Можно сравнить, какое значение Гугл и Яндекс уделяют своим поисковым и рекламным технологиям в процентном соотношении:

YandexDirect — 62%
YandexBot — 38%
Mediapartners-Google — 25%
Googlebot — 75%

Далее AhrefsBot — собиратель беклинков. Бесполезная (а иногда и вредная) нагрузка на сервер. Вредная потому, что конкуренты смогут видеть то, что им видеть не положено. Его блочим в robots.txt.
Поскольку есть сомнения, что он вообще читает robots.txt, то для профилактики делаем примерно так:

if ($http_user_agent ~* (Wget|ApacheBench|SISTRIX|AhrefsBot|Teleport) ) {
    return 502;
}

Ну и Bot openstat, я считаю, вообще недостоин нашего внимания.

PS. Чуть не забыл.
Получить Top список IP-адресов можно так:

cat ваши_лог_фалы | cut -c -15 | sort | uniq -c | sort -nr | sed -r 's!\s*([0-9]+)\s+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+).*!\1\t\2!g' > top.log

А выборку по отдельным ботам можно получить grep‘ом.

Google Chrome и "-" 400 0 "-" "-"

2013-01-24T20:46:00+00:00

Еще раз к вопросу откуда в логах берутся строки вида:

1.1.1.1 - - [19/Jan/2013:07:19:23 +0400] "-" 400 0 "-" "-"

При медленном соединении удалось отловить эффект появления таких записей в браузере и увидеть все вживую.

Вот тут видно, как Chrome отправил два запроса, держит соединение открытым, а потом закрывает:

А секундой позже уже загружает то, что его просили.

Успел сделать снимки экрана.

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

Баним ботов. Часть 2

2013-01-23T14:21:00+00:00

Небольшой анализ логов сервера. Какие странные сущности обитают в Интернете. И как с ними бороться.

Открытые подключения

В логах nginx’а обнаружил десятки тысяч записей вида:

1.1.1.1 - - [19/Jan/2013:07:19:23 +0400] "-" 400 0 "-" "-"
1.1.1.1 - - [19/Jan/2013:07:19:23 +0400] "-" 400 0 "-" "-"
1.1.1.1 - - [19/Jan/2013:07:19:23 +0400] "-" 400 0 "-" "-"
1.1.1.1 - - [19/Jan/2013:07:19:34 +0400] "-" 400 0 "-" "-"
1.1.1.1 - - [19/Jan/2013:07:19:34 +0400] "-" 400 0 "-" "-"
1.1.1.1 - - [19/Jan/2013:07:19:34 +0400] "-" 400 0 "-" "-"
1.1.1.1 - - [19/Jan/2013:07:19:34 +0400] "-" 400 0 "-" "-"

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

Казалось бы, легко создать правило для fail2ban и забанить их всех.

Но такие записи могут создавать и обычные пользователи. Например, если пользователь остановит загрузку или при быстром переходе со страницы на страницу (у меня получилось отловить такой эффект в Google Chrome).

Суть таких записей такова: открытое и не закрытое соединение.

Например, если открыть соединение telnet’ом и оставить его, то по истечении таймаута появится именно такая запись.

$ telnet site.ru 80

Trying 127.0.0.1...
Connected to site.ru.
Escape character is '^]'.

Или можно так:

php -r 'for($i=0;$i>500;$i++){$v="s".$i;$$v=socket_create(AF_INET,SOCK_STREAM,SOL_TCP);socket_connect($$v,"localhost", 80);}'

Особого вреда такие атаки нанести не могут, т.к. в силу своего асинхронного характера nginx может держать достаточно большое число открытых соединений. Но специально для таких случаев (а также других недоатак) существуют такие вещи, как модули ngx_http_limit_req_module и ngx_http_limit_conn_module.

Про них написано достаточно много, простым гуглением все находится.

Можно только добавить — не забыть вставить в robots.txt строчку вроде этой:

Crawl-delay: 1

(можно дробные значения), чтобы ненароком не забанить поисковых роботов.

limit_req_zone должна обязательно стоять (в секции http) до подключения секций server, т.е. до

include /etc/nginx/conf.d/*.conf;

Еще некоторых ленивых роботов, передающих не все заголовки, можно развернуть вот таким кодом в секции server:

if ( $http_user_agent = "" ){
    return 444;
}

try proxy

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

Дело в том, что если, например, telnet’ом передать заголовок не

GET /index.htm HTTP/1.1

GET http://site.ru/index.htm

то nginx не разворачивает такой запрос с кодом 400, а обрабатывает его.

И дальше все зависит от настройки конфигов.

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

В общем случае, если site.ru определён в nginx как

server_name site.ru;

то дальше вашего сервера запрос не уйдет.

Вот реальный пример из log-файла:

178.77.67.27 - - [20/Jan/2013:19:09:43 +0400] "GET http://www.scanproxy.net:80/p-80.html HTTP/1.0" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; KuKu 0.65)"
82.145.35.123 - - [10/Jan/2013:08:11:20 +0400] "GET http://proxyjudge2.proxyfire.net/fastenv HTTP/1.1" 404 564 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
80.82.215.45 - - [01/Jan/2013:08:59:03 +0400] "GET http://www.scanproxy.net:80/p-80.html HTTP/1.0" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; KuKu 0.65)"
62.193.243.32 - - [01/Jan/2013:23:38:53 +0400] "GET http://www.scanproxy.net:80/p-80.html HTTP/1.0" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; KuKu 0.65)"
46.32.65.23 - - [11/Dec/2012:19:20:15 +0400] "GET http://www.santeh.ru/cgi-bin/textenv.pl HTTP/1.0" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)"

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

server {
    listen      80 default_server;
    server_name "";
    return      444;
}

Далее, при передаче заголовка (без HTTP/1.1 или HTTP/1.0):

GET http://site.ru/index.htm

Все остальные строки запроса будут проигнорированы.

Т.е. в запросе (вместо GET /index.htm HTTP/1.1 написано GET http://site.ru/index.htm):

GET http://site.ru/index.htm
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:windows-1251,utf-8;q=0.7,*;q=0.3
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Host:site.ru
Referer:site.ru/index.htm
User-Agent:TelnetTester

Будет учтена только первая строка. А значит, поможет уже знакомая нам конструкция:

if ( $http_user_agent = "" ){
    return 444;
}

Но такая ситуация встречается не часто.

Кроме ботов, запросы вида GET http://site.ru/index.htm HTTP/1.1 шлет Opera. Во всяком случае, у меня в логах достаточно много строк вроде этой:

188.162.15.86 - - [05/Jan/2013:09:18:41 +0400] "GET http://opera10beta-turbo.opera-mini.net:80//img/spb_b_1456.jpg HTTP/1.1" 404 162 "http://images.yandex.ru/yandsearch?p=..." "Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.10"

Битые заголовки

94.41.37.135 - - [11/Jan/2013:08:51:57 +0400] "ЪьЪЮ\x00\x10JFIF\x00\x01\x01\x00\x00\x01\x00\x01\x00\x00ЪЧ\x00;CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 75" 400 166 "-" "-"
176.213.180.115 - - [07/Jan/2013:16:27:16 +0400] "ЪьЪЮ\x00\x10JFIF\x00\x01\x01\x01\x00`\x00`\x00\x00Ъш\x00C\x00\x02\x01\x01\x02\x01\x01\x02\x02\x02\x02\x02\x02\x02\x02\x03\x05\x03\x03\x03\x03\x03\x06\x04\x04\x03\x05\x07\x06\x07\x07\x07\x06\x07\x07\x08\x09\x0B\x09\x08\x08" 400 166 "-" "-"

Такие строки создают некоторые браузеры. Как это происходит — я так и не понял. Но нечто подобное я нашел в логах на локальной машине — там, где никаких ботов быть не может. Предположительно, Google Chrome.

Также весьма вероятно, подобные записи могут создаваться некоторыми ботами, ищущими уязвимости веб-сервера.

Вот, например, http://disorder.ru/archives/908 — человек описал эксплоит для старых версий Nginx, а вот это:

188.138.88.171 - - [19/Jan/2013:20:05:45 +0400] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 166 "-" "-"

50.63.136.60 - - [19/Jan/2013:20:32:27 +0400] "GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1" 400 166 "-" "-"

явно адресовано IIS.

Такие записи просто можно игнорировать. В случае особой настойчивости помогает способ с ngx_http_limit_req_module, описанный в предыдущем пункте.

Баним ботов. Часть 1

2013-01-20T11:07:00+00:00

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

113.204.67.51 - - [19/Jan/2013:07:22:08 +0400] "GET /phpmyadmin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:12 +0400] "GET /PMA/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:17 +0400] "GET /pma/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:17 +0400] "GET /admin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:18 +0400] "GET /dbadmin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:19 +0400] "GET /sql/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:20 +0400] "GET /mysql/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:20 +0400] "GET /myadmin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:21 +0400] "GET /phpmyadmin2/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:22 +0400] "GET /phpMyAdmin2/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:23 +0400] "GET /phpMyAdmin-2/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:23 +0400] "GET /php-my-admin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:24 +0400] "GET /sqlmanager/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:25 +0400] "GET /mysqlmanager/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:26 +0400] "GET /p/m/a/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:26 +0400] "GET /php-myadmin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:27 +0400] "GET /phpmy-admin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:28 +0400] "GET /webadmin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:29 +0400] "GET /sqlweb/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:30 +0400] "GET /websql/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:31 +0400] "GET /webdb/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:31 +0400] "GET /mysqladmin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
113.204.67.51 - - [19/Jan/2013:07:22:32 +0400] "GET /mysql-admin/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"

и решил я всех этих мерзких ботов забанить.

Для чего был создан fail2ban-скрипт phpmyadmin.conf следующего содержания:

 # Fail2Ban configuration file  
 #  
 # Author: Valmat  
 #
 [Definition]
 failregex = ^<host> - - \[.*\] "GET /(phpmyadmin|PMA|pma|admin|dbadmin|sql|mysql|myadmin|phpmyadmin2|phpMyAdmin2|phpMyAdmin-2|php-my-admin|sqlmanager|mysqlmanager|p/m/a|php-myadmin|phpmy-admin|webadmin|sqlweb|websql|webdb|mysqladmin|mysql-admin)/ HTTP/1.1" 404

 ignoreregex =

В /etc/fail2ban/jail.conf нужно добавить секцию:

[phpmyadmin]

enabled = true  
port    = http,https  
filter  = phpmyadmin  
logpath = /var/log/nginx/localhost.access.log  
bantime = 86400  
maxretry = 1

За основу для построения скрипта был взят список:

phpmyadmin
PMA
pma
admin
dbadmin
sql
mysql
myadmin
phpmyadmin2
phpMyAdmin2
phpMyAdmin-2
php-my-admin
sqlmanager
mysqlmanager
p/m/a
php-myadmin
phpmy-admin
webadmin
sqlweb
websql
webdb
mysqladmin
mysql-admin
2phpmyadmin
MyAdmin
admin/db
admin/pMA
admin/phpMyAdmin
admin/phpmyadmin
admin/sqladmin
admin/sysadmin
admin/web
administrator/PMA
administrator/admin
administrator/db
administrator/phpMyAdmin
administrator/phpmyadmin
administrator/pma
administrator/web
database
db
mysql/admin
mysql/db
mysql/dbadmin
mysql/mysqlmanager
mysql/pMA
mysql/pma
mysql/sqlmanager
mysql/web
phpMyAdmin
phpMyadmin
phpmy
phpmyAdmin
phppma
program
sql/myadmin
sql/php-myadmin
sql/phpMyAdmin
sql/phpMyAdmin2
sql/phpmanager
sql/phpmy-admin
sql/phpmyadmin2
sql/sqladmin
sql/sqlweb
sql/webadmin
sql/webdb
sql/websql
PMA2005
pma2005
phpmanager

Учитывая логику работы ботов, то что в первую очередь они простукивают каталоги первого уровня, а лишь затем уровнем выше, этот список можно сократить до такого:

phpmyadmin
PMA
pma
admin
dbadmin
sql
mysql
myadmin
phpmyadmin2
phpMyAdmin2
phpMyAdmin-2
php-my-admin
sqlmanager
mysqlmanager
p/m/a
php-myadmin
phpmy-admin
webadmin
sqlweb
websql
webdb
mysqladmin
mysql-admin
2phpmyadmin
MyAdmin
PMA2005
administrator
database
db
phpMyAdmin
phpMyadmin
phpmanager
phpmy
phpmyAdmin
phppma
pma2005
program

В результате получается приведённый выше конфиг.

Для проверки используем команду:

fail2ban-regex '113.204.67.51 - - [19/Jan/2013:07:22:25 +0400] "GET /mysqlmanager/ HTTP/1.1" 404 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"' '^<host> - - \[.*\] "GET /(phpmyadmin|PMA|pma|admin|dbadmin|sql|mysql|myadmin|phpmyadmin2|phpMyAdmin2|phpMyAdmin-2|php-my-admin|sqlmanager|mysqlmanager|p/m/a|php-myadmin|phpmy-admin|webadmin|sqlweb|websql|webdb|mysqladmin|mysql-admin|2phpmyadmin|MyAdmin|PMA2005|administrator|database|db|phpMyAdmin|phpMyadmin|phpmanager|phpmy|phpmyAdmin|phppma|pma2005|program)/ HTTP/1.1" 404'

Как в PHP узнать протокол (https)

2013-01-17T16:07:00+00:00

Оказывается, узнать, что сайт использует SSL и страница открыта по протоколу https — не настолько тривиальная задача, чтобы решить её с наскока.
Однако, решение оказалось достаточно простое.

Проблема заключается в том, что для определения протокола могут быть использованы переменные:

$_SERVER['HTTPS']
$_SERVER['HTTP_SCHEME']
$_SERVER['HTTP_X_FORWARDED_PROTO']

И косвенно:

$_SERVER['SERVER_PORT']

Но все эти переменные, кроме номера порта, почти наверняка будут отсутствовать.
Определять http-схему, основываясь только на номере порта — приемлемое, но не очень гибкое решение.

Я сделал так:

$scheme = isset($_SERVER['HTTP_SCHEME']) ? $_SERVER['HTTP_SCHEME'] : (
    (
        (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off')
        || 443 == $_SERVER['SERVER_PORT']
    ) ? 'https' : 'http'
);

И для надёжности, чтобы $_SERVER['HTTP_SCHEME'] была определена, в nginx.conf добавил строчку:

# for SSL
fastcgi_param HTTP_SCHEME  $scheme;

Мозаика из фотографий с помощью convert (ImageMagick)

2012-12-06T21:56:00+00:00

Из фотографий или картинок одинакового размера можно сделать мозаику. Получается интересный эффект.

Для этого я написал два bash-скрипта.

Первый уменьшает размеры фотографий, второй делает из миниатюр мозаику.

Скрипт для уменьшения фотографий

#!/bin/bash

SW=150
SH=150
FROMDIR="fromdir"
TODIR="todir"

for name in $(ls $FROMDIR); do
  convert -resize ${SW}x${SH} -strip $FROMDIR/$name $TODIR/$name
done

Здесь:

SW — ограничение ширины миниатюры;
SH — ограничение высоты миниатюры;
FROMDIR — каталог, в котором находятся фотографии;
TODIR — каталог, в который будут сложены миниатюры.

Скрипт для создания мозаики из миниатюр

#!/bin/bash

SW=150
SH=112
COLS=15
REZFILE="mosaic-`date "+%Y-%m-%d_%H_%M_%S"`.jpg"
FDIR="small"

(
echo "convert $(i=0 && for name in $(ls $FDIR | sort -R); do echo -n " -page +$[($i%$COLS)*$SW]+$[(($i-$i%$COLS)/$COLS)*$SH] $FDIR/$name"; i=$[$i+1]; done) -mosaic $REZFILE"
)

Здесь:

SW — ширина миниатюры;
SH — высота миниатюры;
COLS — количество столбцов;
REZFILE — имя файла с мозаикой;
FDIR — каталог с миниатюрами.

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

Чтобы мозаика повторяла пропорции исходных фотографий, должно быть:

SW == SH

Число фотографий должно равняться произведению:

SW * SH

В последнем скрипте используется sort -R для случайного упорядочивания. Если его убрать, будет тот порядок, в котором выдает ls.

Вот пример мозаики из аватарок пользователей сайта:

Установка Redis via unix.socket

2011-12-03T07:05:00+00:00

О том, как установить Redis в качестве сервера на Linux и обращаться к нему через Unix.socket

По мотивам куцей доки: http://redis.io/topics/quickstart и http://redis.io/download

От рута делаем:

mkdir /usr/src/redis
cd /usr/src/redis

wget http://redis.googlecode.com/files/redis-2.4.4.tar.gz
tar xzf redis-2.4.4.tar.gz
cd redis-2.4.4
make && make test

Если тесты прошли нормально (должно быть написано что-то вроде этого: “\o/ All tests passed without errors!”), то двигаемся дальше.

mv ../redis-2.4.4.tar.gz ./redis-2.4.4.tar.gz

cp src/redis-server /usr/local/bin/
cp src/redis-cli /usr/local/bin/

mkdir /etc/redis
mkdir /var/redis

Далее в доке предлагается сделать cp utils/redis_init_script /etc/init.d/redis_6379, где 6379 — номер дефолтного порта, но я планирую, что Redis будет работать у меня через unix.socket, поэтому будет так (везде далее нолик появляется именно по этой же причине):

cp utils/redis_init_script /etc/init.d/redis_0

Теперь нужно подредактировать конфиг:

nano /etc/init.d/redis_0

Редактированию там подлежит только номер порта (6-я строка):

REDISPORT=6379  -->  REDISPORT=0

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

Но в моем случае, поскольку я планирую запускать редис через unix socket, то нужно еще внести несколько изменений:

Добавляем переменную:
```
UNIXSOCK=/tmp/redis.sock
```
Выражение $CLIEXEC -p $REDISPORT shutdown в секции “stop” заменяем на $CLIEXEC -s $UNIXSOCK shutdown.

Вот что получилось:

#!/bin/sh

REDISPORT=0
#REDISPORT=6379
UNIXSOCK=/tmp/redis.sock
OWNER=nobody

EXEC=/usr/local/bin/redis-server
CLIEXEC=/usr/local/bin/redis-cli

PIDFILE=/var/run/redis_${REDISPORT}.pid
CONF="/etc/redis/${REDISPORT}.conf"

case "$1" in
  start)
      if [ -f $PIDFILE ]
      then
              echo "$PIDFILE exists, process is already running or crashed"
      else
              echo "Starting Redis server..."
              $EXEC $CONF
      fi
      ;;
  stop)
      if [ ! -f $PIDFILE ]
      then
              echo "$PIDFILE does not exist, process is not running"
      else
              PID=$(cat $PIDFILE)
              echo "Stopping ..."
              #$CLIEXEC -p $REDISPORT shutdown
              $CLIEXEC -s $UNIXSOCK shutdown
              while [ -x /proc/${PID} ]
              do
                  echo "Waiting for Redis to shutdown ."
                  sleep 0.5
                  echo -n ".."
                  sleep 0.5
                  echo -n ".."
              done
              echo "Redis stopped"
      fi
      ;;
  restart)
      if [ ! -f $PIDFILE ]
      then
              echo "$PIDFILE does not exist, process is not running"
      else
              PID=$(cat $PIDFILE)
              echo "Stopping ..."
              #$CLIEXEC -p $REDISPORT shutdown
              $CLIEXEC -s $UNIXSOCK shutdown
              while [ -x /proc/${PID} ]
              do
                  echo "Waiting for Redis to shutdown ..."
                  sleep 1
              done
              echo "Redis stopped"
      fi
      echo "Starting Redis server..."
      $EXEC $CONF
      ;;
  *)
      echo "Please use start or stop as first argument"
      ;;
esac

Далее нам нужно скопировать файл конфига:

cp redis.conf /etc/redis/0.conf

И отредактировать его:

nano /etc/redis/0.conf

В нем меняем следующее:

#daemonize no
daemonize yes

#pidfile /var/run/redis.pid
pidfile /var/run/redis_0.pid

#port 6379
port 0

bind 127.0.0.1

unixsocket /tmp/redis.sock
unixsocketperm 755

#loglevel verbose
loglevel warning

#logfile stdout
logfile /var/log/redis_0.log

#databases 16
databases 1

В секции “SNAPSHOTTING” можно поменять стратегию дампов. Я сделал так:

save 54000 10
save 3600 5000

dir /var/redis/dumps/
dbfilename dump_0.rdb

Поскольку в сеть смотреть мой редис не будет, то репликацию я в нем отключил (секция ‘REPLICATION’):

#slave-serve-stale-data yes
slave-serve-stale-data no

Далее, поскольку, как и сказано в конфиге, я собираюсь использовать редис не в качестве основной БД, а в качестве кеша, то стоит установить maxmemory, чтобы редис ненароком не сожрал всю память:

# 256 MB
maxmemory 268435456

Поскольку maxmemory установлен, то нужно установить и maxmemory-policy:

# maxmemory-policy volatile-lru
maxmemory-policy volatile-ttl

Выбрал volatile-ttl, потому что не знаю, как работает алгоритм LRU.

Отключаем appendfsync:

appendfsync no

Все, на этом правки конфига закончены.

Для логов мы указывали каталог /var/redis/dumps. Его нужно не забыть создать:

mkdir /var/redis/dumps

Проверяем, все ли работает. Проверить можно так:

Запускаем:

/etc/init.d/redis_0 start

Потом:

redis-cli -s /tmp/redis.sock

В консоли redis:

SET key1 "Test"
OK
GET key1
"Test"

Если все нормально, то добавляем в автозагрузку:

update-rc.d redis_0 defaults

PS
В логах редиса он сообщил мне следующее предупреждение:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

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

В /etc/sysctl.conf ничего, естественно, не вносим, но в /etc/init.d/redis_0
В секции старт, перед запуском редиса, сохраняем системное значение overcommit_memory:

touch /tmp/overcommit_memory_bfr_redis
chmod 0600 /tmp/overcommit_memory_bfr_redis
cat /proc/sys/vm/overcommit_memory > /tmp/overcommit_memory_bfr_redis
sysctl vm.overcommit_memory=1

А в секцию стоп возвращаем системное значение:

OCMSYS=$(cat /tmp/overcommit_memory_bfr_redis)
sysctl vm.overcommit_memory=$OCMSYS

Примерно так:

#!/bin/sh

REDISPORT=0
#REDISPORT=6379
UNIXSOCK=/tmp/redis.sock
OWNER=nobody

EXEC=/usr/local/bin/redis-server
CLIEXEC=/usr/local/bin/redis-cli

PIDFILE=/var/run/redis_${REDISPORT}.pid
CONF="/etc/redis/${REDISPORT}.conf"

#fix WARNING about overcommit_memory
FWOBOM=FALSE

case "$1" in
  start)
      if [ -f $PIDFILE ]
      then
              echo "$PIDFILE exists, process is already running or crashed"
      else
              echo "Starting Redis server..."
              # -- fix WARNING about overcommit_memory
              if [ "TRUE" = $FWOBOM ]
              then
                touch /tmp/overcommit_memory_bfr_redis
                chmod 0600 /tmp/overcommit_memory_bfr_redis
                cat /proc/sys/vm/overcommit_memory > /tmp/overcommit_memory_bfr_redis
                sysctl vm.overcommit_memory=1
              fi
              # <--
              $EXEC $CONF
      fi
      ;;
  stop)
      if [ ! -f $PIDFILE ]
      then
              echo "$PIDFILE does not exist, process is not running"
      else
              PID=$(cat $PIDFILE)
              echo "Stopping ..."
              #$CLIEXEC -p $REDISPORT shutdown
              $CLIEXEC -s $UNIXSOCK shutdown
              while [ -x /proc/${PID} ]
              do
                  echo "Waiting for Redis to shutdown ."
                  sleep 0.5
                  echo -n ".."
                  sleep 0.5
                  echo -n ".."
              done
              # -- fix WARNING about overcommit_memory
              if [ "TRUE" = $FWOBOM ]
              then
                OCMSYS=$(cat /tmp/overcommit_memory_bfr_redis)
                sysctl vm.overcommit_memory=$OCMSYS
              fi
              # <--
              echo "Redis stopped"
      fi
      ;;
  restart)
      if [ ! -f $PIDFILE ]
      then
              echo "$PIDFILE does not exist, process is not running"
      else
              PID=$(cat $PIDFILE)
              echo "Stopping ..."
              #$CLIEXEC -p $REDISPORT shutdown
              $CLIEXEC -s $UNIXSOCK shutdown
              while [ -x /proc/${PID} ]
              do
                  echo "Waiting for Redis to shutdown ..."
                  sleep 1
              done
              echo "Redis stopped"
      fi
      echo "Starting Redis server..."
      # -- fix WARNING about overcommit_memory
      if [ "TRUE" = $FWOBOM ]
      then
        touch /tmp/overcommit_memory_bfr_redis
        chmod 0600 /tmp/overcommit_memory_bfr_redis
        cat /proc/sys/vm/overcommit_memory > /tmp/overcommit_memory_bfr_redis
        sysctl vm.overcommit_memory=1
      fi
      # <--
      $EXEC $CONF
      ;;
  *)
      echo "Please use start or stop as first argument"
      ;;
esac

PPS

overcommit_memory влияет на выделение памяти ядром и на работу OOM Killer.
vm.overcommit_memory=0 — более безопасный вариант, т.к. кто его знает, кого грохнет OOM Killer, если память кончится.
Если tcp сокет устраивает, а нужно только (возможно задать порт), то в каталоге utils с исходниками есть скрипт install_server.sh, запуск которого сделает большую часть грязной работы, описанной выше.
По поводу maxmemory-policy volatile-lru vs volatile-ttl: статья на хабре про LRU

Библиотека для загрузки фотографий на сайт

2011-10-01T11:24:00+00:00

transImage — это PHP библиотека для простой загрузки фотографий на сайт.

Она умеет:

Получать изображение из файла, автоматически нормализовать его размер для экономии памяти
Автоматически поворачивать исходное изображение по данным Exif
Создавать копии себя с изменёнными размерами, изменять свой размер
Наносить водяные знаки. Поддерживает любые водяные знаки, соответствующие интерфейсу waterMark (см. код)
Выводить результат клиенту или сохранять его в файловую систему
Подкладывать белый фон, если исходное изображение поддерживает прозрачность
Быстро создавать миниатюру для предпросмотра, используя миниатюру из Exif
Преобразовывать изображения в строку для использования их с data:URI. В этом случае небольшие изображения можно передавать с другими параметрами в формате JSON (при использовании Ajax)

Для более подробной информации смотрите комментарии в коде.

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

Не рекомендую использовать её для выдачи клиенту (браузеру) изображений больших размеров. Эта функция несёт исключительно демонстративную нагрузку.

Лицензия: BSD.

GitHub repo:

https://github.com/valmat/transImage

Замена салонного фильтра на Fiat Albea

2011-09-02T17:23:00+00:00

Для замены салонного фильтра понадобятся:

фильтр
крестовая отвертка
фонарик
тряпка под коленки
хорошая погода

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

Фильтр находится под бардачком.

Крепится двумя шурупами.

Следующие две фотографии должны сподвигнуть увидевших их на срочную замену фильтра в своей машине. Я не менял фильтр два года.

Я поставил себе угольный фильтр. Его код: 9.7.541 (260 руб. на экзисте).

Можно не извращаться и поставить обычный — будет дешевле. Код обычного фильтра: 9.7.540 (150 руб. на экзисте).

Установка ветровиков на Fiat Albea

2011-09-02T14:58:00+00:00

Наконец-то установил ветровики на свой Фиат.

Вот что получилось:

Код дефлекторов: D07061

Рыбацкие снасти из Китая

2011-04-11T16:22:00+00:00

Сегодня наконец-то пришла моя рыбацкая посылка из Гонконга.

А именно, сделал небольшой пробный заказ на китайском сайте focalprice.com.
До этого заказывал только на dealextreme.com.

Заказывал:

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

Качество товара вполне ожидаемое. Примерно то же самое продаётся у нас в 90% рыбацких магазинов, но за большие деньги.

Воблер пришёл другой расцветки. Я заказывал жёлтого цвета, пришёл серебристый с красной башкой:

Виброхвосты, я ожидал, должны были быть побольше. Но тут уж сам виноват — на сайте размеры указаны. Хотя, впрочем, я не расстроился. Маленькую рыбу тоже нужно чем-то ловить.

Джиги, как видно, тоже маленькие — грамм по пять.

Также обратил внимание, что посылка почему-то шла через Брянск, и на Брянской таможне её вскрывали:

php Cacher

2010-10-30T10:48:00+00:00

Опубликовал набор классов для кеширования:
http://github.com/valmat/Cacher
Опубликовано под лицензией
GPL v.3 (http://www.gnu.org/licenses/gpl.txt)
То есть свободно для использования и изменения. Разумеется, приветствуются любые исправления и дополнения.

Назначение

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

Также немаловажным моментом является возможность прозрачно менять стратегию кеширования в зависимости от текущего уровня нагрузки проекта.

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

Архитектура

Основными логическими единицами являются:

Cacher — фронтенд к кеширующим классам.
Cacher_Backend — собственно сами кеширующие классы.
Слоты — кеширование и доступ к кешу осуществляется через слоты.
Теги — для упрощения управления кешем и, главным образом, для переуеширования.
Типы кеширования — для прозрачного изменения стратегии кеширования. То есть конкретный кеширующий бекенд подключается только через слот (или тег), которые, в свою очередь, оперируют типами. Таким образом, для изменения стратегии кеширования нужно всего лишь поменять привязку типов к бекендам.

Использование

class Cacher

Требует наличия классов, унаследованных от Cacher_Backend — семейство классов, реализующих бэкэнд для класса Cacher.

Все операции с кешем осуществляются на низшем уровне через тот или иной бекенд.

Бэкэндом может быть файловая система, shared memory, memcache, Sqlite и другие системы кеширования.

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

Пример использования

define AnyObj // может быть класс, массив или другой объект. 
// На основании этого объекта слот-функция вычислит ключ и, возможно, другие параметры (бэкэнд и время жизни).
Cacher::Slot('AniObj', AniObj); // Инициализируем слот кеширования. Первый параметр — имя слота, второй — наш объект

// Получаем данные
if (false === ($CacheData = Cacher::get())) { // Если данные из кеша получить не удалось...
    $CacheData = GetFromAnyExternal(); // Получаем данные из внешнего хранилища
    Cacher::addTag(Cacher::newTag('AniTagData', AniTagDataObj)); // Создаем и сразу же добавляем новый тег к слоту перед сохранением в кеш
    $tag2 = Cacher::newTag('AniTagData2', AniTagDataObj1); // Создаем новый тег
    Cacher::addTag($tag2); // Добавляем новый тег к слоту перед сохранением в кеш
    Cacher::set($CacheData); // Кешируем данные
}
// ...
// Если затем нужно сбросить какой-нибудь тег, то нужно будет сделать так:
Cacher::newTag('AniTagData2', AniTagDataObj1)->clear(); // Очищаем кеш тега

define vs const в PHP

2010-10-28T19:00:00+00:00

Как известно, при разработке крупных веб-приложений помимо архитектуры постоянно приходится задумываться также и о производительности. Этим постом я хотел бы открыть серию публикаций по тестированию PHP на производительность.

Речь пойдет о сравнении способов хранения констант в приложении на PHP.
А именно сравниваются два подхода:

define('CONST1', 'val11');
define('CONST2', 'val12');
define('CONST2', 'val13');

class Consts {
    const CONST1 = 'val1';
    const CONST2 = 'val2';
    const CONST3 = 'val3';
}

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

В общем, чтобы не гадать, я провел тесты.

Тест 1. Инициализация

Инициализируем 100 констант при помощи define:

define('CACHER_TYPE_1', 'b60861c4492f88589429aab0c67abdd4');
/*     ...    */
define('CACHER_TYPE_100', 'a66aedeafbc3f1e9fcbaa6a9e8060739');

memory_start: 114.7578125 Кб
time: 0.442981719971 ms
memory_finish: 120.8515625 Кб
memory_diff: 6.09375 Кб

Тестирование через ab:

$ ab -n 1000 http://test/test/mem_class.php
Requests per second:    714.52 [#/sec] (mean)
Time per request:       **1.400** [ms] (mean)

Теперь инициализируем через константы класса:

class SlotType {
    const TYPE_CACHER_1 = 'b60861c4492f88589429aab0c67abdd4';
    /*     ...    */
    const TYPE_CACHER_100 = 'a66aedeafbc3f1e9fcbaa6a9e8060739';
}

memory_start: 114.7578125 Кб
time: 0.0340938568115 ms
memory_finish: 114.9921875 Кб
memory_diff: 0.234375 Кб

Тестирование через ab:

$ ab -n 1000 http://test/test/mem_class.php
Requests per second:    818.27 [#/sec] (mean)
Time per request:       **1.222** [ms] (mean)

Тест 2. Чтение

Считываем все константы, определённые через define:

$var = CACHER_TYPE_1 . CACHER_TYPE_2 . /*...*/ . CACHER_TYPE_100;

time: 0.4 ms
memory_diff: 9.3 Кб

ab -n1000:

Requests per second:    488.63 [#/sec] (mean)
Time per request:       **2.047** [ms] (mean)

Считываем через константы класса:

$var = SlotType::TYPE_CACHER_1 . SlotType::TYPE_CACHER_2 . /*...*/ . SlotType::TYPE_CACHER_100;

time: 0.12 ms
memory_diff: 3.5 Кб

ab -n1000:

Requests per second:    609.62 [#/sec] (mean)
Time per request:       **1.640** [ms] (mean)

Вывод

Надо сказать, результат меня несколько удивил. Я ожидал, что по крайней мере скорость обработки с define будет выше. Оказывается, использование варианта

class Consts {
    const CONST1 = 'val1';
    const CONST2 = 'val2';
    const CONST3 = 'val3';
}

не только удобнее, но и эффективнее как по скорости исполнения, так и по расходу памяти.

PHP Counter

2010-10-28T06:02:00+00:00

Выложил на github.com свой класс Counter.

В основном сделал это, чтобы потестить сам GitHub.

Адрес страницы на гитхабе: http://github.com/valmat/MC_Counter

Как использовать

Класс Counter — это образец реализации счетчика на memcache.

Можно построить другие реализации на общем интерфейсе.
Сохранение результатов применения значений счетчика осуществляется по заданному числу.
Можно реализовать сохранение по заданному интервалу времени.

Конструктор принимает три аргумента: ключ, имя слота и идентификатор для инициализации слота.
Для чего это сделано: инкремент счетчика должен быть очень быстрой операцией.
Не целесообразно тратить время и системные ресурсы на создание объектов, которые не будут использованы.
Поэтому передается только имя класса слота, который создается только в случае необходимости.
К таким случаям относится обмен данными между локальным и постоянным хранилищем счетчика.
Слоты необходимы, так как Counter не может знать о способе хранения данных в постоянном хранилище и путях доступа к ним.
Для предотвращения состояния гонки необходим механизм блокировок.
При наличии блокировки процессы, не получившие эксклюзивные права на получение данных, будут писать во временное хранилище, а процесс, установивший блокировку, по окончании своей работы инкрементирует счетчик данными из временного хранилища.
При сбросе данных в постоянное хранилище по условию достижения кратности значения счетчика ($this->Val % $this->upd_delim), блокировка не требуется, так как в этом случае (при достаточно большом значении $this->upd_delim) в текущий момент времени только один процесс приходит к необходимости сброса данных.

Пример использования

$cnt = new Counter('anykey', 'AnySlot', 15);
echo $cnt->increment();
echo $cnt->get();
echo $cnt->set(11);

Восстановление удалённых и повреждённых данных в Linux

2010-10-18T18:04:00+00:00

Когда-то давно, лет десять назад, случалось мне отформатировать раздел жёсткого диска под Windows. На диске была важная информация, поэтому встала задача данные восстановить. Помню, путём продолжительного гугления были найдены несколько замечательных программ и кряков к ним. И данные были, хоть и частично, но восстановлены. Назывались эти программы, вроде бы, Easy Recovery, Recover4All и какая-то ещё.

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

Поскольку сейчас Windows у меня нет, была найдена чудесная линуксовая утилита под названием foremost.

Вот, всё-таки, за что я люблю Linux — это за лаконичность и изящность решений (ну и за логичность архитектуры, конечно).

Для восстановления данных потребовалась всего одна команда в терминале:

foremost -t jpg -o ~/bak -i /dev/sdb1

Теперь по порядку, что к чему:

# — запускаем от root, чтобы не было проблем с чтением.
-t — тип восстанавливаемых файлов. Можно написать -t all, чтобы восстановить файлы всех типов, либо одно из значений из списка: avi, bmp, dll, doc, exe, gif, htm, jar, jpg, mbd, mov, mpg, pdf, png, ppt, rar, rif, sdw, sx, sxc, sxi, sxw, vis, wav, wmv, xls, zip.
-o ~/bak — куда складывать результат.
-i /dev/sdb1 — здесь указываем раздел, который нужно сканировать. Поддерживаются разные файловые системы. Тот диск, который приносили мне, был с NTFS.

Если запустить с опцией -t all, то будут созданы разные каталоги под каждый тип файлов, что само по себе очень удобно.

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

P.S. Foremost есть в репозитории Ubuntu.
Т.е. установить можно так:

sudo apt-get install foremost

Принтер Canon LBP 3200 в Ubuntu

2010-09-20T16:10:00+00:00

К великому моему сожалению, принтер Canon LBP 3200 не заработал в Ubuntu 9.10 “из коробки”.

Драйверов для него в стандартной поставке нет. Просто скачать и установить драйвер тоже сразу не получилось. Поэтому я решил поискать ответ в интернете.

Мне удалось найти две адекватные ссылки:

Собственно, моя инструкция полностью написана, руководствуясь этими ссылками. К сожалению, обе они по отдельности результата не дали.

Все, что написано ниже, у меня дало положительный результат.

Инструкция для Ubuntu 9.10

Открываем терминал:

sudo su

Удаляем:

libcupsys2 и libstdc++5:

/usr/sbin/ccpdadmin -x LBP3200
sudo /usr/sbin/lpadmin -x LBP320
sudo dpkg -P cndrvcups-capt
sudo dpkg -P cndrvcups-common

Далее скачиваем и устанавливаем libcupsys2 и libstdc++5:

Далее надо скачать драйвер принтера:

sudo su
cd /tmp
wget http://files.canon-europe.com/files/soft31118/software/CAPTDRV180.tar.gz
tar -xzf CAPTDRV180.tar.gz
cd ./CANON_UK/Driver/Debian
dpkg -i cndrvcups-common_1.80-1_i386.deb
dpkg -i cndrvcups-capt_1.80-1_i386.deb

Далее надо отредактировать файл /etc/ccpd.conf:

sudo gedit /etc/ccpd.conf

Меняем строки:

#<Printer  LBP3200>
#DevicePath /dev/usb/lp0
#</Printer>

на

<Printer  LBP3200>
DevicePath /dev/usblp0
</Printer>

Перегружаем сервер печати:

sudo /etc/init.d/cups restart
sudo /etc/init.d/ccpd stop && sudo /etc/init.d/ccpd start

Регистрируем принтер в ccpd:

sudo /usr/sbin/ccpdadmin -p LBP3200 -o /dev/usblp0
sudo /etc/init.d/ccpd stop && sudo /etc/init.d/ccpd start

Окно статуса принтера можно открыть так:

captstatusui -P LBP3200

UPDATE

Поставил Linux Mint 16 64bit (~ Ubuntu 13.10), и в нем моя инструкция, конечно, не подходит.

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

Итак, имеем названную систему.

Скачиваем и устанавливаем deb-пакеты с драйверами от производителя.
Подключаем и включаем принтер. Смотрим, на какой usb-порт он подключился (у меня /dev/usb/lp1). Смотреть нужно тут: /dev/usb

Правим /etc/ccpd.conf:

sudo gedit /etc/ccpd.conf

Меняем строки:

#<Printer  LBP3200>
#DevicePath /dev/usb/lp0
#</Printer>

на

<Printer  LBP3200>
DevicePath /dev/usb/lp1
</Printer>

Добавляем принтер (в архиве с драйверами есть README, можно посмотреть откуда взялись эти строки и на что их менять, если принтер отличается):

sudo /usr/sbin/lpadmin -p LBP3200 -P /usr/share/cups/model/CNCUPSLBP3200CAPTK.ppd -v ccp://localhost:59687 -E
sudo /usr/sbin/lpadmin -p LBP3200 -m CNCUPSLBP3200CAPTK.ppd -v ccp://localhost:59787 -E
sudo /usr/sbin/ccpdadmin -p LBP3200 -o /dev/usb/lp1

Перегружаем сервер печати (см. выше)
Печатаем пробную страницу.

Все!

Что еще обнаружилось:

Нужно добавить /etc/init.d/ccpd в автозагрузку:
```
update-rc.d ccpd defaults 20;
```
Причем, даже после добавления в автозагрузку, нужно перезагружать ccpd. Поэтому еще нужно в /etc/rc.local перед exit 0 добавить:
```
/etc/init.d/ccpd restart
```
Кроме того выяснилось, что в зависимости от того, был ли подключен включенный принтер до загрузки системы или нет, принтеру назначаются разные файлы устройства. Если включен после загрузки ОС, то /dev/usb/lp1, если до — то /dev/usb/lp0.

Чтобы преодолеть эту неприятность, я изобрел следующий костыль:

В /etc/init.d/ccpd в начало секций ccpd_start() и ccpd_stop() (только ccpd_start недостаточно) добавил следующий блок:

###############################
# Fix гуляние портов
if [ -e /dev/usb/lp0 ]; then
    echo "Exist /dev/usb/lp0"
    if [ ! -e /dev/usb/lp1 ]; then
        echo "NOT exist /dev/usb/lp1"
        echo "ln -s /dev/usb/lp0 /dev/usb/lp1"
        ln -s /dev/usb/lp0 /dev/usb/lp1
    fi
fi
###############################

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

Установка LaTeX в Linux Ubuntu

2010-09-08T14:30:00+00:00

Как утверждает Википедия, с 2006-го года пакет teTeX более не поддерживается, а вместо него поддерживается TeX Live. Его и ставим.

Инструкцию по установке подглядел здесь: http://linuxandfriends.com/2009/10/06/install-latex-in-ubuntu-linux/

Ставим:

sudo su
apt-get install texlive texlive-full texlive-fonts-recommended latex-beamer texlive-pictures texlive-latex-extra

texlive-full попросил достаточно много места на диске (около 700 МБ). Место у меня было, поэтому я его всё же установил, но, при необходимости, можно не устанавливать texlive-full, а установить только нужные пакеты, которые входят в texlive-full.

В качестве IDE были на пробу установлены LyX, gedit-latex-plugin и TeXmaker.
Про них пока ничего сказать не могу, т.к. ещё не юзал.

PS: это была моя первая установка LaTeX в Линуксе, до этого я устанавливал MiKTeX под виндой. Как всегда, небо и земля. Вот уж что действительно танцы с бубном, так это ставить МикТех под винду.

Рассказ о том, как я жесткий диск на ноуте менял

2010-08-29T11:16:00-07:00

Был у меня, в общем-то, достаточный для работы жесткий диск объемом 250 ГБ, но не жилось мне спокойно, и захотелось мне поставить жесткий диск на 500 ГБ.

Сказано — сделано. Винт купил и поставил. Надо переносить систему. Переустановка ОС — это не наш путь, разумеется.

Далее будет описано, что я делал (и что не нужно было делать), а в конце — как всё-таки у меня получилось ~~через одно место~~.

Итак, на моем старом винте было три раздела: ntfs, ext4 и swap.

Новый жесткий диск я воткнул в ноутбук, а старый подключил по USB через переноску.

Самое логичное было бы сделать:

dd if=/dev/sdb of=/dev/sda bs=4096 conv=sync,noerror

Но этот способ не сработал. Разделы создались, но файловые системы у них не определились, из-за чего пришлось бы их переформатировать.

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

dd if=/dev/sdb of=/dev/sda bs=512 count=1

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

Всевозможные попытки восстановить grub, осуществляемые при помощи гугления, результата не дали.

Что в итоге я сделал:

Раздел с ntfs оставил как есть (т.е. полностью клонированным со старого жесткого диска).
На раздел ext4, на котором у меня стоял Linux, я заново установил дистрибутив. Устанавливать нужно обязательно тот дистрибутив, который стоял до этого, иначе может не получиться.

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

Затем я полностью стер всё на линуксовом разделе и скопировал при помощи утилиты rsync всё со старого линуксового раздела. Всё это я делал, загрузившись с LiveCD.

rsync в отличие от cp (даже cp -a) нормально копирует скрытые файлы, т.е. те, которые начинаются с “.”. Обе команды rsync -a и cp -a могут копировать атрибуты файлов и права доступа.

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

rsync -a /.../.../  /.../.../

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

Чтобы система начала загружаться, нужно ещё в файлах
/boot/grub/grub.cfg и /etc/fstab
поменять uuid разделов на новые.

Узнать их можно командой:

blkid

Ну и напоследок, поскольку у меня появилось теперь много свободного места, я создал 250-гигабайтный раздел и примонтировал его к /home.

Для этого я всё тем же rsync-ом перенёс все файлы (сидя на LiveCD) на отведённый для этого раздел и прописал в его fstab:

# /home
/dev/sda4    /home  ext4 defaults,noatime,errors=remount-ro 0 2

Разборка HP ProBook 4710s: доступ к памяти

2010-08-17T06:44:00+00:00

Решил я обновить свой ноутбук — увеличить память, да выяснилось, что на HP ProBook 4710s доступ к внутренностям организован не так, как у большинства других моделей, а совершенно через другое место. Поэтому выкладываю здесь инструкцию по открытию этого ноутбука.

Шаг 1:

Снимаем аккумулятор и откручиваем 5 болтов под ним:

Шаг 2:

Затем откручиваем 2 болта на задней части ноутбука:

Складываем все шурупы в одном месте, чтобы не потерять:

Шаг 3:

Толчком от себя снимаем заднюю часть верхней панели (ту, на которой динамики):

Эту часть можно полностью удалить, чтобы не мешала:

Шаг 4:

Далее у нас открывается доступ к болтам крепления клавиатуры:

Их нужно открутить и также толчком от себя (без лишних усилий, это всё же не советская техника — можно и сломать) отделяем клавиатуру:

Вуаля, у нас появился доступ к оперативной памяти:

А дальше я не полез.

Собирается всё, естественно, в обратном порядке.

tmpfs: Операции с файловой системой в виртуальной памяти

2010-07-24T11:08:00+00:00

tmpfs: Операции с файловой системой в виртуальной памяти

Для примонтирования при старте вносим в /etc/fstab:

tmpfs /tmp tmpfs size=500M,nr_inodes=1m,nosuid 0 0
tmpfs /var/lib/php5 tmpfs size=200M,nr_inodes=1m,nosuid 0 0

Первая строчка размещает в памяти /tmp, вторая — папку хранения сессий.

Для создания папки для сессий без рестарта системы нужно выполнить следующую последовательность команд в терминале:

mkdir /tmp/ses
/etc/init.d/nginx stop
mv /var/lib/php5/* /tmp/ses
mount tmpfs /var/lib/php5 -t tmpfs -o size=200M,nr_inodes=1m,nosuid
mv /tmp/ses/* /var/lib/php5
/etc/init.d/nginx start
rm -r /tmp/ses

Предварительно лучше отредактировать fstab.

Вот более сложный вариант, когда данные сессий хранятся в /tmp:

mkdir /dev/shm/ses
/etc/init.d/nginx stop
/etc/init.d/php5-spawn stop
/etc/init.d/mysql stop
mv /tmp/* /dev/shm/ses
mount tmpfs /tmp -t tmpfs -o size=1g,nr_inodes=1m,nosuid
mount tmpfs /var/lib/php5 -t tmpfs -o size=200M,nr_inodes=1m,nosuid
mv /dev/shm/ses/* /tmp
/etc/init.d/mysql start
/etc/init.d/php5-spawn start
/etc/init.d/nginx start
rm -r /dev/shm/ses
du -hsx /tmp

Запуск memcache через unix.socket

2010-07-24T11:04:00+00:00

Запуск memcache через unix.socket

В файл /etc/memcached.conf добавляем строчки:

#-s <file>     unix socket path to listen on (disables network support)
-s /tmp/memcached.socket
#-a <mask>     access mask for unix socket, in octal (default 0700)
-a 0777

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

Перезапускаем демон мемкеша:

/etc/init.d/memcached restart

Подключаемся к Memcache из PHP-скрипта:

$memcache = new Memcache;
$memcache->connect('unix:///tmp/memcached.socket', 0);

Теперь memcache не должен уступать по производительности tmpfs или /dev/shm.

Правда, в этом случае перестают работать сессии в memcached.
То есть следующая конструкция работать не будет:

$session_save_path = 'localhost:11211';
$session_save_path = 'localhost:11211,unix:///tmp/memcached.socket:0';

ini_set('session.save_handler', 'memcache');
ini_set('session.save_path', $session_save_path);

Но для сессий лучше всего всё-таки использовать tmpfs.

Valmat's Personal Blog

Печь для бани с дожигом пиролизных газов

Lost in the Middle. Перевод знаменитой статьи

Потерянные в середине: как языковые модели используют длинные контексты

Аннотация

Введение

Многодокументный вопросно-ответный анализ

Экспериментальная установка

Пример задачи многодокументного вопросно-ответного анализа

Модуляция положения релевантной информации

Модуляция длины входного контекста

Модели

Результаты и обсуждение

Таблица: Точность языковых моделей в закрытой книге и оракульской настройке

Основные выводы

Насколько хорошо языковые модели могут извлекать из входных контекстов?

Экспериментальная установка

Результаты

Почему языковые модели не устойчивы к изменениям положения релевантной информации?

Влияние архитектуры модели

Влияние контекстуализации с учетом запроса

Влияние тонкой настройки инструкций

Всегда ли больше контекста лучше? Тематическое исследование с открытым вопросно-ответным анализом

Связанные работы

Языковые модели с длинным контекстом

Как языковые модели используют контекст?

Эффект серийной позиции

Заключение

Размышления о природе случайности

Что такое хаотическая и стохастическая случайность?

Неравенства Белла: почему они заставляют думать о случайности

Альтернативные взгляды: почему неравенства Белла не закрывают вопрос

Как объяснить объективную случайность

В чём отличие от многомировой интерпретации Эверетта

Почему это минималистично по Оккаму?

Выводы

LittleVec — легковесная векторная база данных

Мотивация и цели

Почему это может быть полезно вам?

Как использовать LittleVec

1. Установка и запуск

Вариант 1: Docker

Вариант 2: Установка через DEB-пакет

Вариант 3: Сборка вручную

2. Быстрый старт с API

Создание базы данных

Добавление векторов

Поиск ближайших векторов

Удаление векторов

3. Дополнительные возможности

Заключение

AI git commit generator

AI для коммитов и тегов: gitai и gitaitag

Что это такое?

Ключевые возможности

gitai:

gitaitag:

Требования

Установка

Использование

Для коммитов — gitai:

Для тегов — gitaitag:

Примечания

Примеры

Ссылки

Утилиты для извлечения изображений и текста из PDF

Установка

Извлечение изображений

Извлечение текста

Получение распределений в задачах регрессии

Мотивация

Описание подхода

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

Построение модели

Ограничения

Итоговый алгоритм

Валидация

Эксперименты

Заключение

Бенчмарк энтропий Шеннона и Реньи на C++

AI для коммитов и тегов: `gitai` и `gitaitag`

`gitai`:

`gitaitag`:

Для коммитов — `gitai`:

Для тегов — `gitaitag`: