Skip to content

ВСЕ ЧТО НУЖНО ЗНАТЬ ПРО LINUX

Подробный разбор устройства Linux: от BIOS и загрузчика до ядра и системных вызовов, объяснение ключевых понятий и процессов.

Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.

Generated from the transcript and can be wrong — check the timestamp.

Key Takeaways

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

What the video covers

  • Linux — это ядро, управляющее железом, а не просто операционная система.
  • Процесс загрузки начинается с BIOS/UEFI, который запускает POST и ищет загрузчик GRUB.
  • GRUB загружает ядро Linux (vmlinuz) и initramfs — временный диск с драйверами для монтирования настоящего диска.
  • Ядро работает в Ring 0 — режиме с полными правами, объединяя драйверы и подсистемы в монолитном пространстве.
  • Основные задачи ядра: управление памятью с помощью виртуальной памяти, планирование процессов и абстракция оборудования.
  • Виртуальная память обеспечивает изоляцию процессов и возможность свопинга, а oomkiller убивает самые ресурсоёмкие процессы при нехватке памяти.
  • Планировщик процессора реализует вытесняющую многозадачность, переключая процессы по квантам времени.
  • Ядро предоставляет универсальный интерфейс для работы с оборудованием, скрывая аппаратные детали от пользовательских программ.
  • Между user space и kernel space существует строгая граница, доступ к оборудованию возможен только через системные вызовы.
  • Пример системного вызова показан на примере Python, где вызов write проходит через libc и ядро для записи данных.

Answers

Questions about this video

Что такое Linux на самом деле?

Linux — это ядро операционной системы, управляющее железом, а не конкретный дистрибутив как Ubuntu или CentOS.

Зачем нужен initramfs при загрузке Linux?

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

Как программы в user space взаимодействуют с оборудованием?

Программы не имеют прямого доступа к оборудованию и используют системные вызовы — специальный API, через который ядро выполняет операции с железом.

Full Transcript — Download SRT & Markdown

00:00
Speaker A
Всем привет. Вы на канале Просто DevOps. Мы часто говорим слово Linux, подразумевая операционную систему Ubuntu, CentOS, Debian, но с инженерной точки зрения это неверно. Linux — это ядро. По сути, кусок кода, который управляет железом. А всё, что мы видим
00:16
Speaker A
на экране, всё, с чем мы взаимодействуем — это просто набор программ, которые крутятся поверх этого ядра. И в этом видео мы разберёмся, как этот самый Linux устроен. Начнём с самого низа, а именно с железа. Нажимаем кнопку питания на сервере. Пошёл ток. Процессор
00:33
Speaker A
просыпается, но в этот момент он пока что тупой кусок кремния. Он не знает, что такое Linux. Он не знает, что такое файлы. Он даже не знает, сколько у него оперативной памяти. Он просто ищет первую инструкцию по жёстко заданному
00:45
Speaker A
адресу. Первый стартует прошивка материнской платы BIOS или же UEFI. Её задача — привести железо в чувство. Она запускает POST power on self-test, проверяет, есть ли память, работает ли видеокарта, инициализировался ли процессор, нашёл ли он оперативку и так далее. Затем она начинает опрашивать
01:05
Speaker A
устройства и ищет, с кого можно загрузиться. Допустим, она нашла жёсткий диск, но BIOS сам не умеет читать файловые системы. Он не знает, что такое EXT4 или XFS. Он не может просто взять и открыть файл, поэтому он считывает самые первые
01:23
Speaker A
512 байт диска. Это MBR или же смотрит в специальный EFI раздел. А там живёт загрузчик. В мире Linux — это почти всегда GRUB 2. GRUB — это маленькая, но умная программа. Её единственная способность — она умеет читать файловую систему. Заглядывает в раздел boot. Там
01:41
Speaker A
лежат два критически важных файла, без которых никакой магии не случится. Первый файл — это vmlinuz Linux. По сути, и есть тот самый Linux. Это само ядро, сжатое в бинарный файл. Буква z в конце означает zip, то есть сжатый. GRUB берёт
01:57
Speaker A
этот файл, распаковывает его прямо в оперативную память и передаёт ему управление. Всё. С этого момента BIOS уходит курить в сторонку, загрузчик умирает. Теперь в системе только один босс — это ядро. И [музыка] вот тут ядро сталкивается с главной инженерной
02:13
Speaker A
проблемой, проблемой курицы и яйца. Ядро загрузилось в память. Его задача — смонтировать наш основной диск, чтобы запустить систему. Но чтобы смонтировать диск, нужны драйверы файловой системы и контроллера диска. А где лежат драйверы?
02:27
Speaker A
Правильно, на том самом диске, который мы ещё не можем прочитать, потому что у нас нет драйверов. Замкнутый круг.
02:34
Speaker A
Именно для этого GRUB загрузил второй файл initramfs. Это маленький временный архив, который разворачивается в оперативной памяти как виртуальный диск.
02:43
Speaker A
Внутри него лежит мини-версия Linux с минимальным набором драйверов. Соответственно, что происходит? Ядро монтирует initramfs как временный корень. Оттуда оно подгружает драйверы для нашего реального железа:
02:56
Speaker A
RAID-контроллеры, NVMe, LVM и так далее. Далее оно находит настоящий большой диск и делает трюк под названием pivot root, то есть смена корня. Ядро выкидывает временный диск из памяти и заменяет его настоящим. Если сервер виснет на этапе загрузки с ошибкой, которую вы видите на
03:14
Speaker A
экране, это значит, что ядро застряло именно в этом моменте. Оно либо не нашло initramfs, либо внутри него не оказалось нужного драйвера для диска. Итак, загрузчик отработал, драйверы подгрузились, мы попадаем в kernel space. С точки зрения архитектуры процессора мы находимся в кольце защиты
03:34
Speaker A
Ring 0. Здесь разрешено всё: любая инструкция процессора или любой адрес памяти. Linux — это монолитное ядро, а не набор разрозненных сервисов. Драйвер видеокарты, сетевой стек TCP/IP, драйвер файловой системы EXT4. Всё это варится в одном гигантском котле в едином адресном
03:54
Speaker A
пространстве. И это даёт дикую производительность, потому что нет накладных расходов на общение между компонентами. Но это повышает риски.
04:02
Speaker A
Если драйвер кривой видеокарты упадёт, он утащит за собой весь сервер в kernel panic. [музыка] А у самого ядра есть три основных задачи. Сейчас посмотрим на каждую из них. Первое — это управление памятью. И на самом деле здесь главная
04:16
Speaker A
задача ядра — врать. Оно врёт нашим программам. Когда условный engines или Python просит память, он думает, что единственный в системе. Для него [музыка] всё выглядит как красивая непрерывная лента адресов. Хотя на самом деле физическая память фрагментирована, и куски данных разбросаны хаотично. Ядро
04:35
Speaker A
использует механизм виртуальной памяти. Оно ведёт гигантскую таблицу, где записано: "Виртуальный адрес X для процесса Ins на самом деле лежит в физической ячейке Y". И это даёт две вещи. Первое — изоляция. Один процесс физически не может залезть в память
04:52
Speaker A
другого. А второе — это свопинг. То есть ядро может незаметно выгрузить часть данных на диск, если оперативка закончилась. Но если память кончилась совсем и своп тоже забит, то приходит oomkiller. И он неспроста так назван. Это буквально киллер, который нанят ядром. Он
05:09
Speaker A
просыпается, сканирует таблицу процессов и находит того, кто ест больше всех и имеет при этом низкий приоритет, и пускает ему пулю в лоб. Например, в том же Kubernetes это происходит постоянно. Если мы неправильно настроим лимиты в кластере, то oomkiller будет приходить и молча
05:26
Speaker A
убивать наше приложение. Вторая задача ядра — делить время между процессами. И для этого существует так называемый планировщик процессора. Допустим, у нас на сервере четыре ядра, а запущено 500 процессов. Как они работают одновременно? [музыка] Никак. Это иллюзия. Ядро использует вытесняющую многозадачность. Оно даёт процессу
05:47
Speaker A
проработать несколько миллисекунд, так называемый квант времени, а потом жёстко его останавливает, и происходит свитч контекста. То есть ядро сохраняет состояние регистров процессора [музыка] для текущей задачи, загружает состояние для следующей задачи и нажимает Play. И это происходит тысячи раз в секунду.
06:06
Speaker A
Если мы видим в мониторинге высокий load average, но процессор не загружен на 100%, возможно, система тратит всё время не на работу, а на бесконечное переключение контекста между тысячами процессов. А про load average у нас, кстати, было видео. Вот оно. Ну и третья
06:23
Speaker A
задача ядра — это абстракция оборудования. Если говорить по-простому, то ядро выступает в качестве переводчика. Программы, которые запущены в user space, то есть наши программы пользовательские, не знают железа. Вот условно у нас есть программа на Python, которая записывает одно слово в файл, но
06:41
Speaker A
только Python не знает, куда он записывает. На самсунговскую SSD, на какой-то старый жёсткий диск или вообще на сетевую шару. У каждого диска свой протокол, свои вольтажи, свои команды контроллера, а ядро предоставляет универсальный интерфейс.
06:55
Speaker A
Программа буквально говорит: "Пиши в этот файл". А драйвер ядра переводит это в электрические сигналы. И благодаря этому наш код работает одинаково на любом железе. Двигаемся выше. У нас есть ядро, которое всем управляет. И есть наши программы, которые хотят что-то
07:12
Speaker A
сделать: прочитать файл, отправить пакет или вывести текст на экран. Но есть проблема. Между режимом пользователя, где живут наши программы, и режимом ядра стоит бетонная [музыка] стена.
07:23
Speaker A
Процессор физически запрещает коду из user space обращаться к оборудованию. И если наша программа пытается напрямую обратиться к диску, процессор немедленно её убьёт с ошибкой Segmentation Fault. И как же нам быть? На самом деле, в этой стене есть одна единственная бронированная дверь. Она называется
07:42
Speaker A
системный вызов. Это строго регламентированный API. Ядро говорит, что оно не пустит нас к диску, но если мы вежливо попросим через специальную функцию, то оно сделает это за нас. И давайте рассмотрим это на примере того же Python. Вот мы пишем print Hello
07:58
Speaker A
World, но происходит целая цепочка событий. Интерпретатор Python вызывает стандартную библиотеку C libc. Библиотека формирует системный вызов write. Она кладёт аргументы в регистры процессора и генерирует специальное программное прерывание. Процессор останавливает программу, переключает режим в ring 0, тот самый режим бога, о котором мы
08:20
Speaker A
говорили в самом начале, и передаёт управление ядру. Ядро проверяет, а есть ли у этого юзера права писать в этот файл. И если всё окей, то ядро рисует пиксел...
08:35
Speaker A
программе. И на самом деле системных вызовов великое множество, их в районе 300-400. Но основные сисколы, которые нужно знать, на которых держится вся база, сейчас у вас на экране. Это Fork Exeg, это Open и Close, это Rit и Right,
08:50
Speaker A
это Socket и Connect. Но зачем это знать именно Divпсу? А потому что программы часто врут. Логи могут быть пустыми, а ошибки неинформативными. Но программа не может врать [музыка] ядру. Она обязана давать все ссколы, чтобы хоть что-то сделать. И здесь на сцену выходит самый
09:07
Speaker A
главный инструмент отладки Sraйс. Это прослушка для сисколов. Мы запускаем Sraйс на какой-то процесс и видим всю подноготную, что он пытался сделать, [музыка] что он получил или на чём он завис. Sraйс - это рентген. Он показывает нам, что программа пытается
09:24
Speaker A
сказать ядру на самом деле. И если вы умеете читать выводст, то для вас не существует непонятных багов. Продолжаем двигаться вверх по стеку. Ядро загрузилось, инициализировало память и драйверы, но сервер всё ещё пустой. В нём нет ни СШ, ни консоли, ни сети.
09:42
Speaker A
Чтобы система ожила, ядро должно запустить самый первый процесс в пространстве пользователя. И для этого оно ищет на диске исполняемый файл по адресу sbin/it и запускает его. Этот процесс получает ПиIT 1, его уникальный айдишник. Все остальные процессы в системе Пит 2, 3, 4.000, 10.000
10:03
Speaker A
будут потомками этого процесса. Если первый процесс умрёт или завершится, яро решит, что система сломалась и вывалится в KNAL Pic и сервер встанет. А в современном Линуксе роль первого процесса выполняет System D. А почему именно System D? Раньше, во времена
10:20
Speaker A
CSway и процессы запускались тупо по очереди. Сначала сеть, потом диск, потом база. Это было долго. System D работает как менеджер зависимостей. Он строит направленный граф, кстати, как в тероформе. Условно говоря, он видит так: зависит от сети, пагress зависит от
10:39
Speaker A
диска, а SSH ни от чего не зависит и запускает всё это параллельно, максимально утилизируя процессор при загрузке. А что физически делает Systemd при старте? Во-первых, он монтирует реальные диски в дерево каталогов.
10:53
Speaker A
Во-вторых, он определяет цель загрузки и, в-третьих, [музыка] начинает поднимать юниты. запускает SSHD, чтобы мы могли подключиться, запускает демон докера, чтобы поднялись контейнеры, и так далее. При этом мы, как админ, не можем просто сказать процессу: "Запустись". Мы общаемся с пиtit
11:13
Speaker A
System CTL. Когда мы пишем System CTL start Engines, по сути, мы отправляем команду System D через определённый сокет. System D, есть ли у нас права, смотрит в зависимости инжинкса и выполняет системный вызов Fork, то есть создаёт копию себя, и exeg, то есть
11:31
Speaker A
заменяет копию на бинарник Инжнкса. Так рождается процесс веб-сервера. Он ребёнок систем D. Итак, процессы запущены, но процессы в вакууме бесполезны. Им нужно читать конфиги, писать логи, сохранять картинки. Мы поднимаемся ещё на следующий уровень абстракции файловой системы. И здесь царит главная философия
11:54
Speaker A
Unix. Всё есть файл. Но давайте разберём это не как лозунг, а как инженерное решение. В винде все привыкли к буквам дисков C, D, E, F и так далее. Это физическое разделение устройств. В Линуксе подход другой. [музыка] Здесь существует единое дерево каталогов. Оно
12:13
Speaker A
всегда начинается с корня, то есть символа слыша. Процессу плевать, сколько у нас дисков. Он видит только дерево. Ну и, соответственно, как это работает физически. Внутри ядра есть прослойка VFS. Виртуальная файловая система. Это точно также универсальный интерфейс. Мы берём условный SSD-диск и говорим ядру.
12:34
Speaker A
Примонтирую его в папку boot. Потом берём сетевой диск и говорим примонтировать его в другой каталог.
12:40
Speaker A
Берём оперативную память и монтируем её в RН. Для программы всё это выглядит одинаково. [музыка] Она просто пишет файлы по путям, а ВФэска сама на лету решает, куда отправить эти байты. По кабелю SAD или по сетевому кабелю на другой сервер. Это и есть прозрачность
12:59
Speaker A
абстракции. Теперь спускаемся ниже. Что такое файл физически? Для нас [музыка] это просто какое-то название, условно photo. JPG, но для ядра имя - это пустой звук. Просто набор байт для удобства кожаного мешка. Для ядра файл - это iнода, индекс нода. Каждый файл в
13:17
Speaker A
системе - это просто номер. В айноде хранится вся метаинформация, кроме имени: кто владелец, какие права доступа, размер файла, тайм-стампы и самое главное, указатели на сектора диска, где физически лежат нулее единицы. А что тогда такое имя файла?
13:34
Speaker A
Имя живёт в каталоге. И технически каталог, то есть папка - это тоже файл, но внутри него лежит простая таблица из двух колонок: имя файла и номерноды. И когда мы, например, выполняем команду C и передаём ей имя файла, то ядро в этот
13:49
Speaker A
момент читает каталог, находит имя, берёт соответствующий номер иноды, потом идёт в таблицу ит, смотрит права и сектора диска и после этого начинает читать данные. Ну, а теперь давайте раскроем концепцию всё есть файл на полную. Помните, мы говорили, что VFS -
14:07
Speaker A
это абстракция? Так, разработчики Линукса подумали: "А зачем нам ограничиваться дисками? Давайте представим само ядро в виде файлов".
14:15
Speaker A
Итак, появились папки проs и SIS. В них нет файлов на диске. Размер этих файлов 0 байт. Это иллюзия, но это прямой интерфейс доступа к структурам данных ядра в оперативной памяти. И, например, когда мы читаем файл процpu ядро не идёт на диск, оно опрашивает
14:34
Speaker A
процессор и генерирует текст ответа на литу. И самое крутое - это работает в обе стороны. Мы можем писать в эти файлы. Хотим включить маршрутизацию пакетов, то есть стать роутером. Нам не надо искать никакую галочку ни в какой панели управления. Мы просто пишем цифру
14:50
Speaker A
один вот в этот файл, который показан на экране. Ядро перехватывает эту запись и меняет переменную в своём коде. Вот что значит всё есть файл. Это универсальный апи для управления системой. Мы разобрались с хранением, то есть с нашими файловыми системами. Теперь
15:06
Speaker A
переходим к исполнению. Что такое запущенная программа? Это процесс. Процесс - это изолированный контейнер в памяти, у которого есть свой PID, свои переменные и свои ресурсы. Но процесс в вакууме бесполезен. Ему нужно получать данные и отдавать результат. И здесь
15:26
Speaker A
снова работает правило, всё есть файл. Когда ядро запускает любой процесс, оно автоматически открывает для него три файла, то есть три канала связи. В таблице файловых дескрипторов они всегда занимают первые три строчки. Первый из них, хотя, вернее сказать, нулевой - это
15:42
Speaker A
DDIN, то есть стандартный ввод. По умолчанию этот файл привязан к нашей клавиатуре. Процесс читает оттуда то, что мы печатаем. Второй - это D out, то есть стандартный вывод. По умолчанию этот файл привязан к нашему экрану, ну или же терминалу. Сюда летит результат.
15:59
Speaker A
Иdr, стандартный вывод ошибок тоже привязан к экрану, но это отдельный поток. А зачем разделили stdout и stdr?
16:07
Speaker A
На самом деле, чтобы мы могли отличить мух от котлет. Если программа работает и сыпет ошибками, мы можем сказать оболочки. Полезные данные, то есть первый индекс, записать в файл data.txt, а ошибки, то есть второй индекс, просто выкинуть в defnal чёрную дыру. В девопсе
16:23
Speaker A
это база логирования. А теперь переходим к главной магии Linux, символу вертикальной черты Pйpe. Это механизм межпроцессного взаимодействия. Возьмём вот эту команду. Как она работает? Ядро запускает процесс C и процесс греп одновременно, но для CAT оно подменяет stdout, то есть выход, и вместо экрана
16:44
Speaker A
оно направляет его в специальный буфер памяти пайп. А для ГЕБ ядро подменяет его, то есть вход. И вместо клавиатуры он подключает его к тому же самому буферу. И в чём гениальность? Процессы КТ и ГП не знают о существовании друг
17:00
Speaker A
друга. Кэт думает, что пишет на экран, а Греб думает, что читает с клавиатуру. Ядро просто переткнуло провода, и это позволяет строить конвейеры любой длины.
17:10
Speaker A
Вот посмотрите на экран. Пять глупых маленьких программ, соединённых пайпами, превращаются в мощный инструмент аналитики. Это и есть подход Юникса.
17:19
Speaker A
писать программы, которые делают одну вещь, но хорошо, и научить их работать вместе через текстовые потоки. Мы разобрались, как процессы работают и как данные летают по пайпам. Но кто решает, кому можно читать файл, а кому нельзя?
17:34
Speaker A
Мы поднимаемся [музыка] на уровень безопасности. В Линуксе безопасность - это не магия антивируса, это простая проверка битов в Вайноде.
17:42
Speaker A
Когда мы логинимся в систему, мы думаем, что пользуемся админкой. Но ядро не знает слов. Ядро знает только цифры.
17:49
Speaker A
Наше имя транслируется в UID, user ID. Наша группа транслируется в Git, Group ID. Это база данных соответствии лежит в простых текстовых файлах PVD и etcoup. И помните, мы говорили пройноды. В каждой аноде записано: "Этим файлом владеет UID такой-то, группа [музыка] такая-то. И
18:09
Speaker A
там же записаны три набора прав: usеer, то есть, что может делать владелец, group, то есть, что может делать группа, иers, что может делать любой другой рандомный процесс. А сами действия примитивны: read, [музыка] то есть читать, write, то есть изменять, и
18:25
Speaker A
execute, то есть сказать ядру, загрузить [музыка] этот файл в память и исполнить как процесс. И каждое действие имеет своё число. read 4, write 2, execute 1.
18:35
Speaker A
Почему именно это? Это не случайные цифры. Это битовая маска в двоичной системы. Чтение - это 100, запись - это 0,10, исполнение - это 01. И когда мы пишем условно чмот 755, мы просто складываем биты. 7 - это 4 + 2 + 1.
18:52
Speaker A
Владелец [музыка] может всё. 5 - это 4 + 0 + 1. То есть группа может читать и исполнять, но [музыка] не писать. Ну и ещё раз пятёрка для всех остальных. И здесь есть важный нюанс. Право [музыка] X, то есть execute для каталога означает
19:07
Speaker A
не запуск, а возможность в него попасть. Если у нас есть права на чтение папки, но нет права на вход, то мы можем увидеть список файлов, но не можем прочитать их метаданные. Но у всех правил есть исключение. [музыка] В
19:19
Speaker A
Линуксе есть один пользователь, для которого ядро отключает проверку прав. Это [музыка] root. У него всегда UID0.
19:27
Speaker A
Когда процесс UID0 делает CS call open, ядро не смотрит в айноду, оно просто открывает файл. Root может читать etcad, где лежат хэши паролей, может убить процессы и ниты, положить сервер, может отформатировать диск на живой системе, поэтому сидеть под рутом - это дурной
19:45
Speaker A
тон и риск. Для администрирования используется [музыка] механизм суда. Это утилита с особым битом SUID, которая временно повышает наш UID до нуля, выполняет одну команду и, что критически важно, записывает это в лок аудита. Так мы получаем безопасность без потери
20:02
Speaker A
контроля. И вот мы поднялись на самый верхний уровень userspace. У нас есть [музыка] ядро, есть файловая система, есть права, но система всё ещё голая.
20:12
Speaker A
Нужен софт, веб-серверы, база данных, утилиты. Как программы попадают в Linux? В Виндоусе все привыкли делать, как идём на сайт, качаем экзэшник, кликаем Next, и каждая программа тащит с собой свои собственные библиотеки. В Линуксе принят инженерный подход. Централизованные репозитории. Это проверенные склады
20:31
Speaker A
бинарных пакетов, которые поддерживаются разработчиками вашего дистрибутива. Здесь работает пакетный менеджер АТ, Яма, ПК. Когда мы пишем APT installings, происходит не просто скачивание.
20:43
Speaker A
Пакетный менеджер - это умный архиватор с базой данных. Он скачивает топ или то rpm пакет, распаковывает файлы строго по стандарту FHS, то есть бинарник [музыка] кладёт в userbin, configги в etc, сервисный файл в lipstem [музыка] D system. Ну а самое важное, он проверяет,
21:01
Speaker A
есть ли у нас нужны библиотеки. Почему это важно? Потому что Linux экономит ресурсы. Программы в Линуксе почти всегда динамически слинкованы. Это значит, что бинарник Джинкса весит копейки. В нём нет кода шифрования, в нём нет кода сжатия. Вместо этого он
21:18
Speaker A
просто [музыка] при запуске говорит ядру: "Мне нужна такая-то библиотека". И ещё вот такая. А сами эти библиотеки шареные. Они лежат в системе в одном экземпляре, обычно в Userер и когда мы запускаем условный Engin SSH клиент и Python Script, все они используют один и
21:35
Speaker A
тот же файл библиотеки. Ядро загружает её в оперативную память один раз, и все процессы просто получают ссылку на этот участок памяти. И это колоссально экономит оперативку, но при этом создаёт сложность. Версии библиотек должны совпадать. Именно поэтому нам нужен
21:52
Speaker A
пакетный менеджер, а не ручное скачивание файлов. Он следит, чтобы версия библиотеки в системе подходила всем установленным программам. А если этот карточный домик рушится, это называется Dependency Hell, то есть ад зависимостей. [музыка] Но в современных дистрибутивах это случается крайне редко. Ну и теперь
22:10
Speaker A
давайте соберём этот пазл воедино. Мы прошли путь от холодного кремния до нашей клавиатуры. Теперь у вас в голове должна быть не каша из команд, а чёткая вертикальная структура. Смотрите на Linux как инженер. Внизу лежит тупое железо, которое разбудил BIOS. Над ним
22:26
Speaker A
стоит диктатор. Ядро. Оно врёт программам про память, нарезает время процессора и управляет драйверами. Между ядром и миром бетонная стена с одним окошком. Никто не проходит мимо. Ядро запускает первого рабочего, который строит всё окружение юзерспейса. И всё это пространство организовано в единое
22:45
Speaker A
дерево, где каждый файл - это просто номер с правами доступа. И на самой вершине сидим мы. Если держать в голове эту схему, магия исчезает. Остаётся чистая, сухая логика. Больше не придётся гуглить ошибки вслепую. Увидим проблему Permission Dight и поймём, что это не
23:03
Speaker A
просто Linux абстракт на ругается, а это ядро при выполнении Cisc Open, сверило наш UID с битами в айноде и вернула код ошибки. А когда сервер тормозит, то есть высокий loadт average, мы понимаем, что это не процессор устал, а это очередь
23:18
Speaker A
процессоров в планировщике стала слишком длинной, и система тратит ресурсы на переключение контекста. А когда нас спрашивают про докер, мы улыбаемся, потому что знаем, что нет никакого докера. Есть просто грамотное использование [музыка] неймспейсов и сигрупсов, которые ядро предоставляет любому процессу. Это и есть инженерное
23:35
Speaker A
мышление. Иникейщик учит команды наизусть, а инженер понимает, как текут байты. Команду можно нагуглить за 5 секунд, а понимание архитектуры нагуглить нельзя, его можно только наработать. И у нас в Телеге мы подготовили для вас полную карту архитектуры Linux одним пдфом. Там
23:52
Speaker A
расписаны основные сисколы, структура файловой системы и этапы загрузки. Это ваша шпаргалка, чтобы картинка всегда была перед глазами. Забираете её в нашем Телеграме, ссылка в описании.
24:03
Speaker A
Перестаньте быть просто пользователями, становитесь инженерами, смотрите в корень. И пока-пока. По
Topics:Linuxядро Linuxзагрузка LinuxBIOSGRUBinitramfsвиртуальная памятьпланировщик процессовсистемные вызовымонолитное ядро

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

Or transcribe another YouTube video here →