Системное программирование *

Go 1.27 (на момент написания rc3, финал обещают в августе) приносит generic-методы: метод наконец может объявить собственный тип-параметр. Взял golang:1.27rc3 в Docker и проверил, где у фичи границы. reflect новый метод не видит вообще, хотя go/types на том же типе показывает его в method set — метод доступен компилятору и недоступен через рефлексию, поэтому ни один интерфейс им не удовлетворить, а валидаторы и ORM его не заметят. Померил цену: на 200 инстанцирований с запретом инлайна бинарь с методом больше на 2264 байта, из которых 2000 приходятся на длину имён символов, а не на код; по времени разницы нет — это generic-функция с ресивером и тот же gcshape-стенсилинг. А вот что реально заметит прод на апгрейде: GODEBUG=asynctimerchan=1 теперь роняет процесс до main, encoding/json v1 на движке v2 меняет байты вывода на битом UTF-8, json.RawMessage обзавёлся String() и поменял ваши логи. Плюс замеры нового аллокатора: минус четверть времени на new(16 B) и ноль на 128 байтах.

Привет, Хабр. Меня зовут Кирилл Балашов, я инженер-программист компании РЕД СОФТ. Мы в РЕД СОФТ изучили подходы к иммутабельным, или же неизменяемым операционным системам, сравнили полностью иммутабельную модель и гибридную, и выбрали гибрид для неизменяемого варианта РЕД ОС 8. Сегодня я расскажу, почему такая операционка удобнее для решения определённого круга enterprise-задач и покажу, как она работает.

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

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

Когда я только знакомился с OSDev, я очень долго искал соответствующие материалы. Находил и на YouTube, и на Habr, и просто какие‑то англоязычные сайты (тогда я не сильно знал английский). Но почти все что я находил было либо незаконченным, либо недостаточно понятным и полным.

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

Не потому, что контейнерному миру срочно нужен ещё один init. Есть Tini, есть docker run --init, и для большинства production-сценариев я бы по-прежнему начал именно с них.

Мне скорее хотелось разобрать задачу до самого нижнего уровня: без libc, без runtime, напрямую через Linux syscalls. Заодно проверить, насколько сильно будет отличаться одна и та же реализация на x86-64 и ARM64.

В итоге из небольшого эксперимента получился mini-init-asm: PID 1, который запускает приложение в отдельной process group, передаёт сигналы всей группе, собирает zombie-процессы и умеет корректно завершать контейнер с exit code приложения.

Позже туда добавились subreaper mode и простой restart-on-crash. А сам проект в итоге доехал сначала до Debian unstable, а затем и до testing.

Но началось всё с вопроса: что вообще должен уметь нормальный PID 1 внутри контейнера?

Привет! Меня зовут Денис Молодяков, я — тимлид команды графики в KasperskyOS. Мы отвечаем за разработку графического стека полного цикла для микроядерной ОС: от создания низкоуровневых графических драйверов до всего необходимого для фреймворков.

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

Пару месяцев назад я решил провести эксперимент и сделать с нуля clean-room имплементацию LINSTOR, используя его референсы и публичные API-типы. Изначально эта идея зародилась как пятничная шутка: я просто хотел уделить этой задаче минимум времени, запустить ее на фоне и посмотреть, к чему это приведёт. Целью было просто проверить, насколько современные нейросети способны к автономной работе без участия человека. 

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

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

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

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

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

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

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

В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.

Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.

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

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

В работе с FASTA и FASTQ таких мест неприлично много. Почти все они когда‑то были задуманы как удобство.

Вот три, с которыми я сталкивался чаще всего.

Первое. Инструмент пишет FASTQ, а качества у записи нет. Вместо ошибки он подставляет строку из I. Файл получается валидный, парсер доволен, а фильтр по качеству дальше по пайплайну видит идеальные риды и пропускает всё подряд.

Второе. R1 и R2 разъехались: один файл отфильтровали, второй забыли. На выходе абсолютно корректный FASTQ, просто риды спарены не с теми. Формат не нарушен ни в одном байте. Ни один валидатор не возразит.

Третье. Определение Phred‑кодировки по образцу, который одинаково хорошо подходит и под Phred+33, и под Phred+64. Инструмент молча выбирает вариант. Иногда правильный.

Общее у всех трёх одно: вместо ошибки вы получаете правдоподобный результат. И это худший из возможных исходов, потому что ошибку вы бы заметили.

Полгода назад я начал писать fastx, библиотеку и CLI для FASTA/FASTQ на Rust. Основное решение в ней сформулировано так: там, где можно либо угадать, либо признать неоднозначность, признавать неоднозначность.

Если в современных реалиях у разработчика возникает необходимость собрать надежное решение для обработки G‑кода, он обычно смотрит в сторону готовых вариантов (GRBL/FluidNC/Linux‑CNC), либо пишет свой кастомный парсер на С/С++ или Rust и для таких проектов вариант реализации на.NET даже не рассматривается ввиду того, что платформа является управляемой и потому недостаточно надежной (заслуженно или нет — разберем далее).

Написал рекурсию тем же приёмом, что во второй статье, и программа повисла навсегда: возвращаться ей было некуда. Чиню, завожу стек и по дороге выясняю, что регистра sp в наборе команд нет вовсе. А потом урезаю стек до 128 байт, и сборка об этом не говорит ни слова.

Это статья про разновидность языка Си с русским и оригинальным английским синтаксисом, работающими одновременно. «Если» и «if» работают как синонимы. Это не интерпретатор. Это компилятор, который способен собрать себя сам. Это даже не транспилятор русского в английский - оба набора слов работают равноценно. Код можно посмотреть https://кодыч.рф/administrator/rusi.

В этой рубрике мы уже рассказывали про Кена Томпсона и Денниса Ритчи, соавторов Unix, UTF-8 и операционной системы Plan 9. Они практически всю жизнь работали вместе в Bell Labs (AT&T, потом Lucent) как коллеги и единомышленники. Так вот, третьим членом их коллектива был Роб Пайк.

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

Без библиотек, без обвязок, без операционной системы под ногами. Реальный код на реальном железе — ну, почти реальном.
Пустая эмулируемая машина RISC-V, десяток строк ассемблера, и в терминале:
Сначала думал вывести «hello», как все.
Пусть будет «Привет, мир!»

Как разработать собственную ОС в одиночку, если заниматься проектом можно только в свободное время? Рассказываю, как ИИ помог мне пройти путь от изучения AArch64 до работающего ядра с вытесняющим планировщиком, userspace, ELF-программами и shell — и почему ответственность инженера при этом никуда не исчезает.

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

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

На Хабре периодически появляются статьи с анализом феномена Python - как один из самых медленных языков программирования стал королём нейросетей, и ответ всегда один: за счёт простого синтаксиса и развитой экосистемы. Но экосистема у C++ значительно больше и богаче, значит, дело не в ней и остаётся только синтаксис. А если проблема действительно в синтаксисе, тогда должен быть ответ и на другой вопрос: почему C++ не стал основой для исследований в этой (или любой другой) области?

Раньше я уже подходил к вопросу об эмпирической оценке сложности синтаксиса языков программирования, что называется «в лоб»: взять исходный код компилятора и посмотреть, сколько строк в нём занимает синтаксический анализатор. Ведь чем сложнее синтаксис, тем больше кода нужно, чтобы его распознать. И сотни тысяч строк кода только на анализ синтаксиса C++ - это измеримое свидетельство того, в какого монстра превратился C++ за сорок лет развития.

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