Начнем с простого вопроса:

Что означает QEMU/KVM или QEMU-KVM?

Можно ответить - это QEMU + KVM или qemu-system, запущенный с kvm в качестве ускорителя. Но в какой-то степени это еще и анахронизм, так как с появлением KVM его разработчики для интеграции с QEMU поддерживали отдельный форк qemu-kvm, но начиная с QEMU версии 1.3 (декабрь 2012) все основные изменения из qemu-kvm были перенесены в главную ветку QEMU, а qemu-kvm объявлен устаревшим.

В разных дистрибутивах до сих пор еще можно встретить исполняемый файл qemu-kvm или просто kvm, но это лишь обертки над qemu-system:

exec qemu-system-x86_64 -enable-kvm "$@"

или симлинки:

/usr/bin/kvm -> qemu-system-x86_64

А в самом qemu существует проверка:

Совсем недавно, 25 января 2022 года вышел новый релиз Nginx - 1.21.6, в котором исправлена проблема неравномерного распределения входящих соединений между несколькими worker процессами в дефолтной конфигурации на Linux системах. Если конкретнее - use epoll, accept_mutex off, reuseport выключен.

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

Насколько я понимаю, эта проблема существует уже более пяти лет и берет начало в версии 1.11.3 (Jul 2016), когда в Nginx по умолчанию отключили accept_mutex, а вместо него стали полагаться на флаг EPOLLEXCLUSIVE, появившийся в ядре Linux 4.5.

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

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

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

В 2017 году, Per Vognsen - программист с более чем 15-летним стажем, работавший в таких компаниях как NVIDIA и Oculus берет паузу и в марте 2018 стартует амбициозный обучающий проект Bitwise, в котором он собирается разработать и написать весь программно-аппаратный стек для простого компьютера с нуля и запустить его на FPGA. 

Проект должен был включать в себя операционную систему, компилятор, системные библиотеки, а также HDL код для центрального процессора и периферийных контроллеров. Пререквизиты к нему минимальны - свободное владение языком Cи (и немного Python), а также знание некоторых алгоритмов и структур данных из стандартных CS курсов. Все остальное объясняется по ходу написания кода.

Проекты подобные Bitwise можно пересчитать по пальцам (думаю многие еще вспомнят о знаменитом Handmade Hero от Casey Muratori). Автором данного проекта выступает отличный программист, который в формате скринкастов показывает и объясняет каждое решение по ходу написания кода. Этой короткой статьей я бы хотел заполнить пробел и познакомить большее число людей с проектом Bitwise, так как сам извлек из него много нового.

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

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

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

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

Строка с шаблоном должна была включать поддержку следующих метасимволов:

^ - начало строки

$ - конец строки

. - любой символ

* - 0 или более раз

? - 0 или 1 раз

+ - 1 или более раз

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

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

Данная статья является четвертой в цикле (1, 2, 3), посвященном изучению исходного кода Docker и прямым продолжением предыдущей статьи, которую мне пришлось преждевременно завершить в виду зависания редактора хабра. В этой статье мы закончим изучать код первого публичного релиза Docker v0.1.0. Будут рассмотрены оставшиеся команды по управлению контейнерами, сетевой стек, а также создание образа и запуск контейнера.

Данная статья является третьей в цикле (1,2), посвященном изучению исходного кода Docker и прямым продолжением предыдущей статьи, в которой мы начали разбирать код первого публичного релиза Docker v0.1.0. В этой части будет рассмотрена реализация практически всех команд, а в конце, мы создадим образ и запустим докер контейнер на его основе. Для удобства я постарался разбить список команд на условные группы: работа с образами, работа с контейнерами, сетевой стек и т.д. 

А теперь, как говорится, “without further ado”, приступим к изучению кода из файла commands.go начиная с команд для управления образами (images).

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

Изначально я планировал уложить весь материал, посвященный этой версии, в одной статье, но в процессе стало ясно, что она получается слишком большой, поэтому я решил разделить ее на две. В текущей части (2.1) будет рассмотрена лишь общая структура и начальный код, а последующая часть (2.2) будет посвящена принципу работы и коду конкретных команд.

Некоторые части кода уже были разобраны в первой статье, так что для полноты восприятия, рекомендую начать с нее, а также пятиминутной презентации The Future of Linux Containers, на которой и была представлена первая версия Docker.

20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.

Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер. 

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

Поиск решения алгебраических уравнений оказал колоссальное влияние на развитие математики. Формула решения общего кубического уравнения впервые была получена итальянскими математиками 16-го века. Это событие ставшее первопричиной рассмотрения комплексных чисел, считается одним из поворотных моментов в истории математики. Судьбы Джероламо Кардано, Никколо Тартальи, Сципиона дель Ферро и их поисков решения кубического уравнения заслуживают отдельного романа со своими интригами, скандалами и расследованиями. Столь яркие истории достаточно редки в математике. 

Начиная с 19-го века поиск формул для решения уравнений произвольных степеней положил начало теории групп и абстрактной алгебре, которые преобразили практически все разделы современной математики. Думаю, многие, кто интересовался историей и развитием алгебры, знают, что формулы для решения общего алгебраического уравнения степени выше четвертой не существует. Как сообщается, первое доказательство этого факта было дано итальянским математиком Паоло Руффини в самом конце восемнадцатого века, оно составляло около 500 страниц и все же содержало некоторые пробелы. Хотя отдельные математики, как Огюстен Коши, и признавали данное доказательство, но ввиду столь большого объема и сложности изложения, оно так и не было принято математическим сообществом. Считается, что первое полное доказательство дано норвежским математиком Нильсом Абелем и содержалось в двух работах, изданных в 1824 и 1826 годах. С тех пор оно носит название теоремы Абеля или теоремы Абеля-Руффини.