⚡️ Деннис Ритчи и Стив Джобс умерли в одном месяце: одного оплакивал весь мир, второго почти не заметили

Об этом факте регулярно вспоминают в сообществе разработчиков, но и сейчас он продолжает бить в больную точку. Стив Джобс и Деннис Ритчи ушли в одном и том же месяце одного и того же года, в октябре 2011. Их уход превратился в символ того, насколько по-разному мир относится к людям, которые формируют технологии.

Джобса оплакивали планетой, выпускали книги, сняли фильмы, именем назвали улицы. Он подарил iPhone, iPad, iPod и Macintosh, собрал вокруг Apple одну из самых дорогих компаний в истории. Денниса Ритчи провожали разве что в узком кругу и парой статей в блогах. Это был человек, который подарил нам язык C и вместе с Кеном Томпсоном Unix.

Дальше просто пройдёмся по цепочке. Без C нет Unix. Без Unix нет Linux, нет BSD, нет macOS и iOS. Без C не было бы Windows в его нынешнем виде, не было бы C++, Objective-C, Java, JavaScript в их привычном виде. Нет Chrome и Firefox, нет PostgreSQL и SQLite, нет Nginx, нет Photoshop, нет PlayStation и Xbox. Даже Python и PHP написаны на C.

При таком влиянии Ритчи оставался человеком, которого было сложно представить на сцене с черной водолазкой и в режиссёрском свете. Он работал в Bell Labs, носил бороду, избегал интервью и писал программы. Человек, без которого современный цифровой мир просто не выглядел бы так, как сейчас, провёл жизнь в тени своих собственных результатов.

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

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

🖥 Linux под капотом: как mknod превращает железо в файлы и почему это магия номер 133

Принцип "всё есть файл" в Linux часто звучит как маркетинговый слоган, хотя на самом деле это базовое инженерное решение, на котором держится вся система. Жёсткий диск /dev/sda, терминал /dev/tty и даже мышка открываются и читаются точно так же, как обычный текстовый файл. Возникает закономерный вопрос: каким образом физическая железка вообще оказывается в файловой системе?

Вся магия упирается в один привилегированный системный вызов: mknod. На архитектуре x86_64 у него номер 133. Именно он создаёт специальный узел в файловой системе, и именно через него ядро понимает, какой драйвер должен обработать обращение к этому пути.

В отличие от обычного файла, при вызове mknod никто не выделяет блоки на диске. Вместо хранения данных создаётся связка пути с парой чисел: major и minor. Major-номер указывает ядру на конкретный драйвер, а minor-номер уточняет конкретное устройство внутри этого драйвера. Считайте их координатами, по которым ядро бьёт в нужную точку без поиска.

Именно поэтому команда cat /dev/urandom не читает никаких байт с накопителя. Файловая система видит специальный узел, перенаправляет запрос в генератор случайных чисел ядра, и вы получаете бесконечный поток энтропии. На диске при этом не лежит ровным счётом ничего.

Поскольку создание такого узла фактически даёт прямой доступ к драйверу ядра, вызов требует capability CAP_MKNOD. Без прав процесс получит EPERM и быстро поймёт, что раздавать доступ к железу от имени обычного пользователя ядро не собирается. Это дополнительный барьер безопасности поверх обычных прав на файлы.

Ниже пример на C, который полностью клонирует /dev/null. Major-номер 1 в ядре зарезервирован под memory devices, а minor-номер 3 указывает именно на null. Запускать нужно от root.

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/sysmacros.h>
#include <stdio.h>

int main(void) {
    // 1 = major number for memory devices
    // 3 = minor number for the null device
    dev_t dev = makedev(1, 3);

    // S_IFCHR creates a character device file
    if (mknod("my_null", S_IFCHR | 0666, dev) == -1) {
        perror("mknod failed (try running with sudo)");
        return 1;
    }

    printf("Successfully created my_null!\n");
    return 0;
}

После компиляции и запуска появится файл my_null, который ведёт себя как исходный /dev/null. Любой вывод, перенаправленный в этот файл, попадёт в тот же самый null-драйвер ядра. Различий в поведении по сравнению с системным /dev/null не будет вообще.

Такой пример хорошо показывает, почему инженеры Unix в своё время свели работу с железом к файловым операциям. Вместо десятков разных API для дисков, терминалов и сети программист получает единый интерфейс read, write, open и close. А вся сложная матчасть по маршрутизации запросов прячется внутри mknod и пары major/minor.

👣 На Stepik обновили курс «Rust: полный курс разработчика. С нуля до профи»

Представьте: через три месяца вы открываете чужой Rust-код и читаете его как книгу.

Arc<Mutex<T>> не вызывает панику. impl Future не пугает. Вы точно знаете, почему компилятор ругается и как это починить за 10 секунд.

Это не фантазия. Это результат 50 уроков, в которых каждая концепция объясняется через код и закрепляется практикой.

Ownership, traits, generics, async, unsafe - всё, что казалось магией, станет рабочим инструментом.

А бонусом - портфолио проектов: от CLI-утилит до REST API и WebAssembly.

Вы и так знаете, что Rust - ваш следующий язык. Этот курс просто сделает это реальностью.

Сегодня - 55% процентов от цены, торопись: https://stepik.org/a/269250/