Вы правы, создателям инструментов разработки эти знания пригодятся больше, чем разработчикам ПО.
Согласен с тем, что большая часть логики живёт в ld-linux. Но все же сначало работает ядро (парсит структуру, загружает программу и компоновщик).
Исходное предложение было написать свой код, который вручную парсит ELF, выделяет память, загружает библиотеки. И вот здесь без реализации «части ядра» действительно не обойтись, потому что:
именно ядро первым читает ELF, находит .interp и загружает ld-linux;
именно ядро создаёт адресное пространство процесса и выполняет начальные mmap для сегментов;
ld-linux работает уже внутри этого пространства, доводя загрузку до конца.
Так что если мы хотим написать свой «ручной» загрузчик в пользовательском пространстве (в существующей ОС), то нам всё равно не обойтись без системных вызовов ядра (mmap, mprotect и т.д.). А часть логики ядра (создание адресного пространства, загрузка интерпретатора) мы просто не можем взять на себя – это привилегия ядра.
Поэтому, соглашусь с вами, нам достаточно реализовать только компоновщик (ядро мы все равно не обойдем) в случае x86. Но если все же речь про голое железо контроллеров, то без реализации части ядра (небольшой ОС) уже не обойтись.
У меня совсем скромный опыт работы с контроллерами. Делал с нуля электронику для управляемой машинки через Wi-fi на базе ESP-07. Только чтобы получить базовые навыки)
Можете написать мне в ВК, обсудим) а то здесь не по теме уже получается)
Большое спасибо всем за обратную связь. Через месяц, когда закроется возможность комментирования, внесу сразу все уточнения и исправлю неточности, которые выявляются через наше обсуждение.
Обязательно добавлю про особенность загрузки статических бинарников. Их загрузка не такая интересная, но для полноты картины стоит их упомянуть. Спасибо за дополнение!
Да, вы правы. Мы же сейчас рассматриваем запуск программы «под strace». Вот так будет корректнее?
Когда вы запускаете strace ./empty_sleep, утилита strace создаёт свою копию с помощью fork(), а затем эта копия вызывает системный вызов execve() для запуска вашей программы. Если бы вы запускали программу напрямую (./empty_sleep), тогда execve() вызывала бы копия оболочки bash.
Двенадцать лет назад я не проверил как будет переводиться сокращенная версия названия, а потом менять было поздно) Во всяком случае спасибо за почетное второе место.
Кстати, полное название изначально было CodeBrain :)
Спасибо за основательный разбор! Тема веб-сокетов обычно воспринимается как чёрный ящик: есть connect, есть send, а что там внутри уже не важно, если это работает. Но ровно до первого 1006 или странного поведения за прокси.
Особенно полезно, что вы прошлись по RFC, показали реальную структуру фрейма с битовыми масками и механизм маскирования. Вы хорошо объяснили про маскирование и то, что это не шифрование, а защита от атак на промежуточные прокси. Многие действительно думают, что маскировка нужна для конфиденциальности, хотя на самом деле история именно про то, чтобы вредоносный JS не мог сэмулировать HTTP-запрос и отравить кеш.
И отдельный респект за упоминание backoff при переподключении. Это та деталь, о которой часто забывают даже в коммерческих проектах, а потом сервер ложится от одновременной волны переподключающихся клиентов.
Единственное, что можно добавить для тех, кто хочет копнуть глубже: полезно заглянуть в исходники production-библиотек, например websockets для Python или реализацию в стандартной библиотеке asyncio. Там видно, как те же самые механизмы (фрейминг, контрольные сообщения, обработка закрытия) реализованы с учётом реальных случаев, таймаутов и правильной работы с памятью.
Ещё раз спасибо за качественный материал. Такие статьи помогают лучше понимать инструменты, которыми мы пользуемся.
Отличный материал, Сергей! Как раз тот случай, когда бэкендер честно признаёт, что раньше не понимал, а теперь видит картину целиком.
Особенно зашла мысль про API как язык общения, который должен быть удобен обеим сторонам. Как раз думаю добавить на Codebra задание, где нужно будет взаимодействовать с разными типами API, чтобы на практике показать эту проблему. Часто человек учит JavaScript, пишет код, но когда дело доходит до реального общения с бэкендом, начинаются танцы с бубном. Склеивание ответов от нескольких эндпоинтов, трансформация данных на клиенте, костыли с кешированием. Хочется в задании как раз подсветить, что проблема часто не в коде, а в том, как спроектировано API.
Про GraphQL и BFF отдельное спасибо. Многие до сих пор думают, что GraphQL является какой-то сложной штукой от Facebook, и проходят мимо. А на деле это просто инструмент, который в нужном месте даёт фронту дышать чуточку свободнее. Думаю в своих материалах сделать разборы когда и что лучше использовать: REST, GraphQL или BFF. Потому что джуны часто учат технологии, а надо учить выбирать инструмент под задачу.
И отдельное спасибо за примеры из реального мира: Netflix, Vercel, Shopify. Это не просто теория для собеседований, а то, как реально строятся современные высоконагруженные системы. Буду ссылаться на статью в своих материалах как на хороший обзор для тех, кто хочет копнуть глубже.
Отличная статья! С пунктом про placeholder вместо label в целом согласен, что это частая проблема, особенно в сложных формах. Но тут, мне кажется, всё же зависит от аудитории и контекста. Для простых полей (поиск, подписка по email) и молодой аудитории placeholder может быть достаточно, так как люди и так понимают, что вводить. А вот для пожилых пользователей, в сложных сценариях (оформление заказа и т.д.) или длинных анкетах думаю что label обязателен. Так что скорее нужно знать когда использовать, чем никогда не использовать.
А вообще статья заставила задуматься. Честно признаюсь, в своих курсах на Codebra я доступности не уделял должного внимания. Всё больше про «Как сверстать макет», а про то «Как сделать доступно для всех» как-то упускал. Ваши пять пунктов отличная затравка, теперь буду пересматривать программу и добавлять интенсив про доступность.
Отличный обзор! Про ToggleEvent.source даже не задумывался, а ведь и правда элегантное решение для многих сценариев. Но closedby для меня лично главное открытие. Сколько кода писал, чтобы закрывать модалки по клику на оверлей, а тут просто атрибут в HTML и готово.
Такие статьи особенно ценны, когда показывают, как современные API сокращают код и убирают зависимость от JS.
Кстати, вдохновившись твоим примером, теперь думаю добавить на Codebra небольшое практическое задание как раз на отработку closedby и ToggleEvent. Хочется сделать пример, где нужно переделать старую модалку, которая висела на JS-костылях, на чистый HTML с новыми атрибутами и через событие toggle выводить, какой именно кнопкой её закрыли.
Спасибо за статью, буду ссылаться на неё в пояснениях к заданию, когда сделаю!
Автору спасибо за разбор. Особенно за специфику современных псевдо-классов :where() и :is(), о которых реально многие забывают.
Судя по комментариям, главная проблема сейчас не в формулировке ответов, а в перенасыщении рынка. Люди годами учат теорию, проходят собесы, но так и не могут попасть на хорошие позиции. Просто заучить правильные ответы на 20 вопросов не поможет.
Сейчас проходят только те, кто может не просто дать определение «специфичности», а сразу объяснить, как она поведет себя в реальном проекте с :nth-child и :has(), и зачем это вообще нужно.
Я последнее время вообще пришел к выводу, что заучивать теорию вообще нет смысла, главное знать как ее применить на практике. Что касается верстки, чтобы человек не просто прочитал про гриды, а сразу руками покрутил, как меняется распределение высоты при grid и при flex, и закрепил это на практике.
Если очень хочется на собеседовании проверить глубину знаний в верстке, то лучше, например, предложить сверстать интерактивную карту солнечной системы на чистом HTML/CSS. Это намного лучше покажет, на что способен человек.
Статья полезная. Но тем, кто реально хочет пройти собес в 2026 году, советую не читать ответы, а идти писать код.
Понял вас, спасибо за уточнения)
В любом случае, добавил в заметки, тема интересная.
Вы правы, создателям инструментов разработки эти знания пригодятся больше, чем разработчикам ПО.
Согласен с тем, что большая часть логики живёт в ld-linux. Но все же сначало работает ядро (парсит структуру, загружает программу и компоновщик).
Исходное предложение было написать свой код, который вручную парсит ELF, выделяет память, загружает библиотеки. И вот здесь без реализации «части ядра» действительно не обойтись, потому что:
именно ядро первым читает ELF, находит .interp и загружает ld-linux;
именно ядро создаёт адресное пространство процесса и выполняет начальные mmap для сегментов;
ld-linux работает уже внутри этого пространства, доводя загрузку до конца.
Так что если мы хотим написать свой «ручной» загрузчик в пользовательском пространстве (в существующей ОС), то нам всё равно не обойтись без системных вызовов ядра (
mmap,mprotectи т.д.). А часть логики ядра (создание адресного пространства, загрузка интерпретатора) мы просто не можем взять на себя – это привилегия ядра.Поэтому, соглашусь с вами, нам достаточно реализовать только компоновщик (ядро мы все равно не обойдем) в случае x86. Но если все же речь про голое железо контроллеров, то без реализации части ядра (небольшой ОС) уже не обойтись.
Или я вас неправильно понял?
У меня совсем скромный опыт работы с контроллерами. Делал с нуля электронику для управляемой машинки через Wi-fi на базе ESP-07. Только чтобы получить базовые навыки)
Можете написать мне в ВК, обсудим) а то здесь не по теме уже получается)
Согласен с вами. Для полноты картины обязательно нужно упомянуть вызов
fork. С него все начинается.Большое спасибо всем за обратную связь. Через месяц, когда закроется возможность комментирования, внесу сразу все уточнения и исправлю неточности, которые выявляются через наше обсуждение.
Ох, ну это очень сложная и глубокая тема. По сути, необходимо реализовать часть ядра (даже мини-ОС) и свой динамический компоновщик.
Боюсь этот материал не уберется даже в рамки одной статьи.
Но идея классная: максимальное погружение в тему загрузки программы в память для выполнения, через практическую реализацию этого механизма.
Такое глубокое понимание точно может пригодиться реверс-инженерам и разработчикам прикладного ПО (в меньшей степени).
Спасибо за идею, добавлю в заметки. Возможно, вернусь к этому позднее, когда сам буду более готовым.
В общем, готов подискутировать на эту тему, если неправильно вас понял)
Большое спасибо)
Думаю тему многопоточности лучше раскрывать в отдельной статье, а то эта и так перегружена.
Обязательно добавлю про особенность загрузки статических бинарников. Их загрузка не такая интересная, но для полноты картины стоит их упомянуть. Спасибо за дополнение!
Да, вы правы. Мы же сейчас рассматриваем запуск программы «под strace». Вот так будет корректнее?
Когда вы запускаете
strace ./empty_sleep, утилитаstraceсоздаёт свою копию с помощьюfork(), а затем эта копия вызывает системный вызовexecve()для запуска вашей программы. Если бы вы запускали программу напрямую (./empty_sleep), тогдаexecve()вызывала бы копия оболочки bash.Двенадцать лет назад я не проверил как будет переводиться сокращенная версия названия, а потом менять было поздно) Во всяком случае спасибо за почетное второе место.
Кстати, полное название изначально было CodeBrain :)
Полностью согласен. Думаю чтобы не объяснять коллегам, им нужно хотя бы раз попробовать реализовать модалку на dialog, чтобы понять всю их простоту.
На основе вашей статьи сделал небольшой интенсив, в котором нужно переписать модалку без использования JavaScript.
Будем вместе искоренять страх перед новыми возможностями)
Спасибо за основательный разбор! Тема веб-сокетов обычно воспринимается как чёрный ящик: есть connect, есть send, а что там внутри уже не важно, если это работает. Но ровно до первого 1006 или странного поведения за прокси.
Особенно полезно, что вы прошлись по RFC, показали реальную структуру фрейма с битовыми масками и механизм маскирования. Вы хорошо объяснили про маскирование и то, что это не шифрование, а защита от атак на промежуточные прокси. Многие действительно думают, что маскировка нужна для конфиденциальности, хотя на самом деле история именно про то, чтобы вредоносный JS не мог сэмулировать HTTP-запрос и отравить кеш.
И отдельный респект за упоминание backoff при переподключении. Это та деталь, о которой часто забывают даже в коммерческих проектах, а потом сервер ложится от одновременной волны переподключающихся клиентов.
Единственное, что можно добавить для тех, кто хочет копнуть глубже: полезно заглянуть в исходники production-библиотек, например
websocketsдля Python или реализацию в стандартной библиотекеasyncio. Там видно, как те же самые механизмы (фрейминг, контрольные сообщения, обработка закрытия) реализованы с учётом реальных случаев, таймаутов и правильной работы с памятью.Ещё раз спасибо за качественный материал. Такие статьи помогают лучше понимать инструменты, которыми мы пользуемся.
Отличный материал, Сергей! Как раз тот случай, когда бэкендер честно признаёт, что раньше не понимал, а теперь видит картину целиком.
Особенно зашла мысль про API как язык общения, который должен быть удобен обеим сторонам. Как раз думаю добавить на Codebra задание, где нужно будет взаимодействовать с разными типами API, чтобы на практике показать эту проблему. Часто человек учит JavaScript, пишет код, но когда дело доходит до реального общения с бэкендом, начинаются танцы с бубном. Склеивание ответов от нескольких эндпоинтов, трансформация данных на клиенте, костыли с кешированием. Хочется в задании как раз подсветить, что проблема часто не в коде, а в том, как спроектировано API.
Про GraphQL и BFF отдельное спасибо. Многие до сих пор думают, что GraphQL является какой-то сложной штукой от Facebook, и проходят мимо. А на деле это просто инструмент, который в нужном месте даёт фронту дышать чуточку свободнее. Думаю в своих материалах сделать разборы когда и что лучше использовать: REST, GraphQL или BFF. Потому что джуны часто учат технологии, а надо учить выбирать инструмент под задачу.
И отдельное спасибо за примеры из реального мира: Netflix, Vercel, Shopify. Это не просто теория для собеседований, а то, как реально строятся современные высоконагруженные системы. Буду ссылаться на статью в своих материалах как на хороший обзор для тех, кто хочет копнуть глубже.
Отличная статья! С пунктом про placeholder вместо label в целом согласен, что это частая проблема, особенно в сложных формах. Но тут, мне кажется, всё же зависит от аудитории и контекста. Для простых полей (поиск, подписка по email) и молодой аудитории placeholder может быть достаточно, так как люди и так понимают, что вводить. А вот для пожилых пользователей, в сложных сценариях (оформление заказа и т.д.) или длинных анкетах думаю что label обязателен. Так что скорее нужно знать когда использовать, чем никогда не использовать.
А вообще статья заставила задуматься. Честно признаюсь, в своих курсах на Codebra я доступности не уделял должного внимания. Всё больше про «Как сверстать макет», а про то «Как сделать доступно для всех» как-то упускал. Ваши пять пунктов отличная затравка, теперь буду пересматривать программу и добавлять интенсив про доступность.
Спасибо за пинок в правильную сторону!
Отличный обзор! Про
ToggleEvent.sourceдаже не задумывался, а ведь и правда элегантное решение для многих сценариев. Ноclosedbyдля меня лично главное открытие. Сколько кода писал, чтобы закрывать модалки по клику на оверлей, а тут просто атрибут в HTML и готово.Такие статьи особенно ценны, когда показывают, как современные API сокращают код и убирают зависимость от JS.
Кстати, вдохновившись твоим примером, теперь думаю добавить на Codebra небольшое практическое задание как раз на отработку
closedbyиToggleEvent. Хочется сделать пример, где нужно переделать старую модалку, которая висела на JS-костылях, на чистый HTML с новыми атрибутами и через событиеtoggleвыводить, какой именно кнопкой её закрыли.Спасибо за статью, буду ссылаться на неё в пояснениях к заданию, когда сделаю!
Автору спасибо за разбор. Особенно за специфику современных псевдо-классов :where() и :is(), о которых реально многие забывают.
Судя по комментариям, главная проблема сейчас не в формулировке ответов, а в перенасыщении рынка. Люди годами учат теорию, проходят собесы, но так и не могут попасть на хорошие позиции. Просто заучить правильные ответы на 20 вопросов не поможет.
Сейчас проходят только те, кто может не просто дать определение «специфичности», а сразу объяснить, как она поведет себя в реальном проекте с :nth-child и :has(), и зачем это вообще нужно.
Я последнее время вообще пришел к выводу, что заучивать теорию вообще нет смысла, главное знать как ее применить на практике. Что касается верстки, чтобы человек не просто прочитал про гриды, а сразу руками покрутил, как меняется распределение высоты при grid и при flex, и закрепил это на практике.
Если очень хочется на собеседовании проверить глубину знаний в верстке, то лучше, например, предложить сверстать интерактивную карту солнечной системы на чистом HTML/CSS. Это намного лучше покажет, на что способен человек.
Статья полезная. Но тем, кто реально хочет пройти собес в 2026 году, советую не читать ответы, а идти писать код.