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

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

Вероятно, вы слышали о планировщике Go раньше, но насколько хорошо мы знает о том как он работает? Как он связывает горутины с потоками?

Разберем по очереди операции, которые выполняет планировщик.

Некоторые паттерны стало возможно использовать на практике только благодаря безопасности Rust по памяти, а на C++ они слишком опасны. В статье приведён один такой пример.

Работая над внутренней библиотекой, написанной на Rust, я создал тип ошибок для парсера, у которых должна быть возможность сделать Clone без дублирования внутренних данных. В Rust для этого требуется указатель с подсчётом ссылок (reference-counted pointer) наподобие Rc.

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

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

10% — 100%

36% — достаточно сильно уверен

39% — уверен в некоторой степени

15% — представления не имею

Меня удивило, что люди не уверены в своём понимании: я-то считала, что HEAD — это довольно простая тема.

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

Привет, Хабр!

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

В этой статьи рассмотрим основные возможности для работы с ресурсами в C.

В этой статье я хотел бы поговорить о том, почему вы могли бы предпочесть использование Arc<[T]> вместо Vec<T> в качестве варианта по умолчанию в вашем Rust-коде.

Python-разработчики, как правило, хорошо знают, что такое и для чего нужен GIL, вопросы по нему встречаются на большинстве собеседований, я и сам люблю их задавать. Но в CPython его скоро не будет. Да, core-разработчики CPython взяли курс на его удаление.

Разберём основные концепции того, как это будет произведено, с обзором соответствующего PEP 703.

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это седьмая статья из серии, список предыдущих статей приведен в конце в разделе 10. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена концепции константности в C++.

Переменные являются основой любого языка программирования. Если значение переменной нельзя изменить после инициализации, то такие переменные называются неизменяемыми (immutable) переменными или константными переменными или просто константами. Константные переменные в том или ином виде поддерживаются во всех языках программирования и играют в них важную роль. Такие переменные помогают компилятору оптимизировать код, улучшают читаемость и надежность кода, позволяют выявлять бОльшее количество ошибок на стадии компиляции. Константы помогают решать проблемы, связанные с многопоточным доступом к переменным. Использование константных переменных влияет на проектные решения в объектно-ориентированном программировании, а функциональное программирование изначально исходит из неизменяемости используемых переменных.

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

Доброго времени суток, дорогие читатели! Сегодня я затрону одну интересную тему — графические дисплейные сервера и протоколы в Linux. В этой статье я расскажу вам о архитектуре X11 и Wayland, историю их создания и наконец-то сделаем вывод: Иксы на мороз, или вейланд на помойку?

Еще в далеком 2016 году вышла Fedora 25 с окружением GNOME 3.22 на базе дисплейного сервера Wayland. А в RHEL 10 выкинут X11 на мороз. Релиз RHEL 10 намечен на 2025 год, CentOS Stream 10 — на 2024 год. Для обеспечения работы приложений, требующих X11, будет использоваться XWayland. Таким образом, в 2029 году (к моменту окончания первого этапа поддержки RHEL 9) стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11.

И как я думаю — будущее за Wayland. Но пока X11 является стандартом. Давайте разберем это!

В начале года на YouTube-канале DevOps Toolkit вышло видео с разбором WebAssembly. Автором ролика является Виктор Фарчич (Viktor Farcic) — developer advocate в Upbound, член CNCF Ambassadors, Google Developer Experts, CDF Ambassadors и GitHub Stars.

Мы перевели видео про WebAssembly в текстовый формат и адаптировали для лучшего понимания. В нём автор разбирает, что такое WebAssembly, стоит ли использовать его в браузерах и кластерах Kubernetes или вообще заменить Kubernetes и прочее.

❯ Кэши для отдельных ядер процессора

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это шестая статья из серии, список предыдущих статей приведен в конце в разделе 7. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена объявлению и инициализации переменных.

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

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

В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.

Окружение

Это необязательно, но я рекомендую подготовить систему для отладки ядра Linux с QEMU + gdb. Если вы никогда этого не делали, то попробуйте такой репозиторий: easylkb (сам я им никогда не пользовался, но слышал о нём много хорошего), а если не хотите настраивать окружение самостоятельно, то подойдёт режим практики в любом из заданий по Kernel Security на pwn.college (вам нужно знать команды vm connect и vm debug).

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

Привет, Хабр!

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

Один из способов, с помощью которого Rust достигает полиформизма, - использование Trait-объектов.

(Читать с толикой сарказма…) Все, кто работал с Ansible, знают, что он не хранит состояние результата своей работы. Это нелепое поведение Ansible, нельзя взять и просто удалить из git объекты конфигурации, чтобы они исчезли с управляемых систем, фу. При этом сразу вспоминается его величество Terraform с tfstate. Всех, кого раздражает подобное положение дел, прошу под кат.

Короткий ответ: нет. Тем не менее, раз про это вновь и вновь спрашивают на Reddit, Stack Overflow и других сайтах, пришло время подробно разобрать эту тему. Оказывается, есть много интересного, о чём можно порассуждать.

Рассмотрим, как устроены GPIO-драйверы в Linux, и почему это сделано именно так. Поймем, почему для простого мигания светодиодом в этой операционной системе надо пройти через N слоев абстракции.