В любом случае, добавил в заметки, тема интересная.

Согласен с тем, что большая часть логики живёт в ld-linux. Но все же сначало работает ядро (парсит структуру, загружает программу и компоновщик).

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

• именно ядро первым читает ELF, находит .interp и загружает ld-linux;

• именно ядро создаёт адресное пространство процесса и выполняет начальные mmap для сегментов;

• ld-linux работает уже внутри этого пространства, доводя загрузку до конца.

Так что если мы хотим написать свой «ручной» загрузчик в пользовательском пространстве (в существующей ОС), то нам всё равно не обойтись без системных вызовов ядра (mmap, mprotect и т.д.). А часть логики ядра (создание адресного пространства, загрузка интерпретатора) мы просто не можем взять на себя – это привилегия ядра.

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

Или я вас неправильно понял?

Можете написать мне в ВК, обсудим) а то здесь не по теме уже получается)

Боюсь этот материал не уберется даже в рамки одной статьи.

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

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

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

В общем, готов подискутировать на эту тему, если неправильно вас понял)

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

Когда вы запускаете strace ./empty_sleep, утилита strace создаёт свою копию с помощью fork(), а затем эта копия вызывает системный вызов execve() для запуска вашей программы. Если бы вы запускали программу напрямую (./empty_sleep), тогда execve() вызывала бы копия оболочки bash.

На основе вашей статьи сделал небольшой интенсив, в котором нужно переписать модалку без использования JavaScript.

Будем вместе искоренять страх перед новыми возможностями)

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

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

Единственное, что можно добавить для тех, кто хочет копнуть глубже: полезно заглянуть в исходники production-библиотек, например websockets для Python или реализацию в стандартной библиотеке asyncio. Там видно, как те же самые механизмы (фрейминг, контрольные сообщения, обработка закрытия) реализованы с учётом реальных случаев, таймаутов и правильной работы с памятью.

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

Особенно зашла мысль про API как язык общения, который должен быть удобен обеим сторонам. Как раз думаю добавить на Codebra задание, где нужно будет взаимодействовать с разными типами API, чтобы на практике показать эту проблему. Часто человек учит JavaScript, пишет код, но когда дело доходит до реального общения с бэкендом, начинаются танцы с бубном. Склеивание ответов от нескольких эндпоинтов, трансформация данных на клиенте, костыли с кешированием. Хочется в задании как раз подсветить, что проблема часто не в коде, а в том, как спроектировано API.

Про GraphQL и BFF отдельное спасибо. Многие до сих пор думают, что GraphQL является какой-то сложной штукой от Facebook, и проходят мимо. А на деле это просто инструмент, который в нужном месте даёт фронту дышать чуточку свободнее. Думаю в своих материалах сделать разборы когда и что лучше использовать: REST, GraphQL или BFF. Потому что джуны часто учат технологии, а надо учить выбирать инструмент под задачу.

И отдельное спасибо за примеры из реального мира: Netflix, Vercel, Shopify. Это не просто теория для собеседований, а то, как реально строятся современные высоконагруженные системы. Буду ссылаться на статью в своих материалах как на хороший обзор для тех, кто хочет копнуть глубже.

А вообще статья заставила задуматься. Честно признаюсь, в своих курсах на Codebra я доступности не уделял должного внимания. Всё больше про «Как сверстать макет», а про то «Как сделать доступно для всех» как-то упускал. Ваши пять пунктов отличная затравка, теперь буду пересматривать программу и добавлять интенсив про доступность.

Спасибо за пинок в правильную сторону!

Такие статьи особенно ценны, когда показывают, как современные API сокращают код и убирают зависимость от JS.

Кстати, вдохновившись твоим примером, теперь думаю добавить на Codebra небольшое практическое задание как раз на отработку closedby и ToggleEvent. Хочется сделать пример, где нужно переделать старую модалку, которая висела на JS-костылях, на чистый HTML с новыми атрибутами и через событие toggle выводить, какой именно кнопкой её закрыли.

Спасибо за статью, буду ссылаться на неё в пояснениях к заданию, когда сделаю!

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

Сейчас проходят только те, кто может не просто дать определение «специфичности», а сразу объяснить, как она поведет себя в реальном проекте с :nth-child и :has(), и зачем это вообще нужно.

Я последнее время вообще пришел к выводу, что заучивать теорию вообще нет смысла, главное знать как ее применить на практике. Что касается верстки, чтобы человек не просто прочитал про гриды, а сразу руками покрутил, как меняется распределение высоты при grid и при flex, и закрепил это на практике.

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

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