LinuxCamp | DevOps

Подошла к концу конференция C++ Russia 2024. Что могу сказать: супер организация, супер доклады, спикеры просто гении не из мира сего (люди разрабатывают статичесие анализаторы, профилировщики и, что самое страшное, игры на Metal API 😮).

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

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

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

Лично для меня было довольно значимым событием наконец-то увидеть вживую Илью Мещерина. Если кто не в курсе Илья - это один из самых толковых "медийных" преподавателей по C++. На самом деле, кроме него, из русских в голову приходит только Виндертон, но тут речь больше про Computer Science. Чем удивил Илья - своей простотой, энергичностью, умением грамотно и структурированно преподносить материал. Хоть я и не сильно горю алгоритмикой, просмотрел все выступление на одном дыхании.

Наш путь в продвижении качественного обучения только начинается, работаем вместе, меняем ход IT!

Компоновка с динамическими библиотеками [3]

Последним из основных способов оповестить динамический компоновщик о местонахождении библиотек является набор соответствующих записей в файле "/etc/ld.so.conf". Как мы знаем, из коробки компоновщику известно несколько путей, по которым могут лежать библиотеки (lib, /usr/lib).

Для того, чтобы расширить этот список, можно внести набор соответствующих записей в конфиг (ld.so.conf), который используется программой ldconfig для того, чтобы создать необходимый компоновщику бинарный кэш "/etc/ld.so.cache" с информацией о всех зависимостях, найденных по заданным путям. Анализируя данный кэш, загрузчику станет понятно, какая библиотека требуется приложению на этапе выполнения.

Почему компоновщик не читает ld.so.conf напрямую? Чтение кэша - более быстрая процедура, относительно анализа файла конфигурации: нужно проверить инклуды, пройтись по файловой системе, открыть каждый файл, считать его содержимое, найти зависимости. С таким подходом потребовалось бы значительное количество дополнительных операций на этапе выполнения для того, чтобы связаться с библиотекой - лишние тормоза и задержки нам ни к чему.

Если посмотреть внутрь ld.so.conf, можно увидеть следующее:

$ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
/usr/lib/mysql

Это значит, что содержимое всех файлов с сигнатурой <filename>.conf в каталоге "/etc/ld.so.conf.d/" будет рассмотрено при формировании итогового кэша:

$ ls /etc/ld.so.conf.d/
libc.conf

$ cat /etc/ld.so.conf.d/libc.conf
/usr/local/lib

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

После внесения изменений в конфиг, необходимо обязательно обновить кэш, иначе пути, которые вы прописали, останутся без внимания компоновщика:

$ sudo ldconfig

Подводя черту, можно сказать, что динамические библиотеки, необходимые программе, ищутся в нескольких местах со следующим приоритетом:

1. (только для ELF) Если исполняемый файл содержит запись DT_RPATH с какими-либо каталогами, то поиск будет выполнен по ним.

2. Если определена переменная среды LD_LIBRARY_РАТH, то поиск будет выполнен последовательно по каждому каталогу, который в ней указан. Если исполняемый файл устанавливает пользовательский (SUID) или групповой (SGID) идентификатор, то переменная игнорируется. Это делается в целях безопасности, чтобы не дать пользователю обмануть динамический компоновщик, заставив его загрузить вместо требуемой библиотеки ее приватную версию с тем же именем.

3. (только для ELF) Если исполняемый файл содержит запись DT_RUNPATH с какими-либо каталогами, то они будут использованы во время поиска.

4. Проверяется файл /etc/ld.so.cache на наличие записи для соответствующей зависимости. Если бинарный файл был связан с опцией компановщика "-z nodeflib", библиотеки в путях по умолчанию (lib и /usr/lib), будут пропущены.

5. Выполняется поиск по каталогам lib и /usr/lib (именно в таком порядке). Если бианрный файл был связан с опцией компановщика "-z nodeflib", данный шаг будет пропущен.

Компоновка с динамическими библиотеками [2]

Мы уже познакомились с двумя способами оповещения динамического компоновщика о местоположении разделяемых библиотек:

1. Определение переменной среды LD_LIBRARY_РАТН.
2. Установка библиотеки в один из стандартных каталогов (lib, /usr/lib).

Но есть и третий путь: на этапе статической сборки в исполняемый файл (приложение либо разделяемую библиотеку) можно встроить список каталогов, по которым требуется производить поиск. Для этого можно воспользоваться параметром компоновщика -rpath:

/* определяем путь "./lib/demo/", как значение для поля DT_RPATH/DT_RUNPATH в исполняемом файле prog */
$ gcc -Wl,-rpath=./lib/demo/ -o prog prog.c -L=./lib/demo/ -ldemo

$ gcc -Wl,rpath=./demo2/ -shared -o libdemo.so mod1.o -L=./demo2 -ldemo2

Результатом компоновки будет запись метки RUNPATH в ELF файле:

$ readelf -d prog

Dynamic section at offset 0xd78 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdemo.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [./lib/demo/]
 
 $ ldd prog
 libdemo.so => ./lib/demo/libdemo.so (0x0000ffffb7790000)

Данный способ бывает полезен:

1. На этапе локальных сборок приложений. Вместо того, чтобы всегда указывать переменную окружения LD_LIBRARY_PATH, можно прописать 2 сценария сборки (debug/release) - в последнем сборка происходит без -rpath и все библиотеки устанавливаются в директории, о которых динамический компоновщик в курсе.

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

Разница между DT_RPATH и DT_RUNPATH:

В былые времена спецификация формата ELF допускала исключительно встраивание DT_RPATH, однако в последующих версиях данного формата эта метка считается устаревшей - в качестве замены был представлен DT_RUNPATH.

Разница между двумя указанными записями заключается в их приоритете относительно переменной среды LD_LIBRARY_PATH: DT_RPATH переопределяет LD и обрабатывается с наибольшим приоритетом, DT_RUNPATH имеет меньший вес и рассматривается сразу после LD.

По умолчанию современные версии компоновщика записывают значение -rpath в метку DT_RUNPATH. Чтобы задействовать вместо этого DT_RPATH, следует дополнительно указать параметр --disable-new-dtags:

$ gcc -g -Wall -Wl,--disable-new-dtags,-rpath=./lib/demo \
   -o prog main.c -L=./lib/demo/ -ldemo
    
$ objdump -p prog | grep PATH
RPATH ./lib/demo/

Использование переменной $ORIGIN в списке rpath:

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

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

Для решения данной проблемы динамический компоновщик позволяет указать в параметре -rpath специальную строку, $ORIGIN, которую он умеет анализировать и интерпретировать как «каталог, содержащий приложение». Это значит, что поиск динамических зависимостей будет происходить по пути, относительно тому, в котором приложение установлено:

$ gcc -Wl,-rpath,'$ORIGIN'/lib/demo ...

$ objdump -p prog | grep PATH
RPATH $ORIGIN/lib/demo/

Теперь можно предоставить пользователю простой установочный пакет с программой и необходимыми библиотеками, который он сможет установить в любое место и успешно запуститься. Как говориться, "Дело сделано" - принимайте работу под ключ.

Компоновка с динамическими библиотеками [1]

Перед применением библиотеки необходимо выполнить 2 дополнительных шага, которые не требуются для работы со статическими аналогами:

1. Поскольку исполняемый файл не содержит копии необходимых объектных модулей, он должен иметь возможность определять, какая разделяемая библиотека требуется для работы. Для этого, на этапе статической компоновки, в ELF файл программы внедряется метка DT_NEEDED с именем библиотеки.

Если говорить чуть более точно, то в поле DT_NEEDED записывается полный путь до библиотеки. Если зависимость находится в неизвестном компоновщику каталоге, то лучше указать дорогу через флаг -L, иначе потом может возникнуть вопрос "Почему зависимость находится корректно при ее локальном размещении?" - потому что ее полый путь записан в поле NEEDED.

$ gcc -Wall -o prog main.o -L=./libs/ -ldemo

// Выводим содержимое динамической секции ELF файла
$ readelf -d ./prog
    
Dynamic section at offset 0xd88 contains 28 entries:
   Tag        Type                         Name/Value
    0x0000000000000001 (NEEDED)             Shared library: [libdemo.so]
    0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

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

Компоновщик, сам по себе, является разделяемой библиотекой “/lib/ld-linux.so.2” и используется всеми исполняемыми файлами формата ELF, которые содержат динамические зависимости.

На самом деле, Id-linux.so.2 представляет собой обычную символическую ссылку на библиотеку динамического компоновщика “Id-<version>.so” (например, ld-2.11. so), где version - это версия glibc, которая установлена в системе.

Если на данном этапе попробовать запустить программу, выведется следующее сообщение об ошибке:

$ ./prog

./prog: error in loading shared libraries: libdemo.so: 
    cannot open shared object file: No such file or directory

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

Часть этих правил основывается на списке стандартных каталогов, в которых обычно хранятся разделяемые библиотеки (lib и /usr/lib). Причина ошибки выше заключается в том, что библиотека находится в текущем каталоге, который не учитывается при поиске.

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

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

Следовательно, можно запустить программу с помощью следующей команды:

$ LD_LIBRARY_PATH=./libs ./prog

Динамические библиотеки

Для устранения недочетов статических библиотек были придуманы динамические (разделяемые).

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

Разделяемые библиотеки обладают следующими преимуществами:

1. Общий размер программ уменьшается, в связи с чем они могут быстрее загружаться в память и, как следствие, запускаться. Это относится только к большим разделяемым библиотекам, которые уже используются другими процессами. На самом деле, программа, которая первой начинает использовать библиотеку, запускается дольше остальных, т.к. с ее инициализацией происходит поиск библиотеки и выгрузка ее в память.

2. Объектные модули не копируются в исполняемые файлы, поэтому можно изменять исходный код библиотеки без необходимости выполнения повторной компоновки. Полностью осознать данное преимущество поможет вымышленный пример, где стандартная библиотека C (libc) является статической. Если кто-нибудь найдёт и исправит баг в printf, то каждая программа должна будет заново пройти компоновку для того, чтобы заполучить исправленный код.

Использование динамических библиотек действительно полезно в случае, когда они являются необходимыми для большинства программ и имеют внушительный размер (QT/GTK).

Однако за эти дополнительные возможности приходится платить:

1. Динамические библиотеки более сложные по сравнению со статическими - как с точки зрения самой концепции, так и в плане создания и компоновки внутри программ.

2. Излишняя зависимость: если в библиотеку было внесено изменение, нарушающее ее совместимость с приложением, запуск будет невозможен. Со статически собранным вариантом такой проблемы не наблюдается, т.к. в нем все необходимые объектные файлы хранятся в виде копий.

3. Перемещение символов должно выполняться во время работы программы: этот процесс требует дополнительных работ, в том числе, выгрузки ядром разделяемой библиотеки динамического линковщика ld-linux.so для связывания на этапе выполнения. Все это приводит к затратам по времени, поэтому программа может работать немного медленнее статически скомпонованного аналога.

Для сборки динамической версии библиотеки необходимо выполнить:

/* -Wall - выводит предупреждения, вызванные потенциальными ошибками в коде, не препятствующими компиляции программы, но способными привести, по мнению компилятора, к тем или иным проблемам на этапе выполнения. */

// -fPIC - завставляет компилятор сгенерировать адресно-независимый код.
$ gcc -c -fPIC -Wall module1.c module2.c module3.c

/* -shared - указывает gcc, что в результате должен быть собран не исполняемый файл, а разделяемый объект - динамическая библиотека. */
$ gcc -shared -o libdemo.so module1.o module2.o module3.o

Разбор пакетов: build-essential

Метапакет в Linux, который включает в себя все основные зависимости и инструменты, необходимые для создания debian сборок из исходного кода. Пакет является Debian-специфичным, поэтому отсутствует в репозиториях для Fedora/RedHat/CentOS и т.д.

Сам по себе не является программой, он всего лишь содержит список зависимостей, которые менеджер apt считывает и устанавливает в систему. Так как готовый пакет может включать бинарь программы, build-essential ставит соответствующие инструменты для компиляции и компоновки.

Главное - не считать его супер решением, которое магическим образом установит все необходимое рабочее окружение для Ruby, Go, Python и т.д. В первую очередь, пакет содержит список базовых инструментов для сборки (.deb) образов.

Некоторыми компонентами являются:

1. gcc/g++: стандартные C/C++ компиляторы в среде разработки Linux.
2. libc6-dev: заголовочные и объектные файлы, необходимые для сборки приложений, использующих стандартную библиотеку C.
3. util-linux: различные утилиты командной строки (chroot, fdisk, mount).
4. dpkg-dev: инструменты, необходимые для создания и управления пакетами в формате (.deb).
5. make: универсальный инструмент для автоматизации сборки программ.

sudo apt install build-essential

Версионирование разделяемых библиотек:

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

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

Корректно спроектированная динамическая библиотека должна состоять из 3 имен:

1. Реальное имя - название самой библиотеки “lib<name>.so.<major>.<minor>.<patch>”. Напрямую при линковке не используется (разве что для дебага).

Major - меняется в случае, когда правки приводят к несовместимости с приложениями (изменение API).
Minor - меняется при расширении API (добавлении функционала).
Patch - багфиксы, оптимизации (изменение функционала внутри готового API).

2. SONAME - метка, которая записывается в файл библиотеки на этапе создания (DT_SONAME в терминологии формата ELF). Именно она встраивается статическим компоновщиком в программу и, как следствие, используется динамическим компоновщиком для поиска на этапе выполнения. Структура, обычно, следующая “lib<library name>.so.<major>”.

/* Создаем libdemo.so.1.0.0 с меткой libdemo.so.1 */
$ gcc -shared -Wl,-soname=libdemo.so.1 -o libdemo.so.1.0.0 module1.o

3. Компоновочное имя - используется на этапе статического связывания приложения и библиотеки (не содержит номеров версий).

/* В исполняемый файл prog будет записан soname, к которому приведет нас libdemo.so */
$ gcc -g -Wall -o prog main.o libdemo.so

Для того, чтобы корректно подключить зависимость, нужно создать 2 символьные ссылки:

1) связывает компоновочное имя и soname;
2) связывает soname и реальное имя библиотеки;

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

libdemo.so -> libdemo.so.1
libdemo.so.1 -> libdemo.so.1.0.0
libdemo.so.1.0.0

После корректного обновления библиотеки, ссылка soname должна указывать на самую последнюю ее версию, в результате чего, ваше приложение будет работать с актуальным экземпляром.

libdemo.so.1 -> libdemo.so.1.0.1

Если обновление меняет мажорную версию, то, при использовании утилиты ldconfig, автоматически будет создана ссылка, связывающая soname и имя библиотеки. При этом, приложение будет работать с последней совместимой версией (если не была удалена).

$ sudo ldconfig -v | grep libdemo
libdemo.so.2 -> libdemo.so.2.0.0 (changed)

/* Выводим диинамические зависимости программы */
$ ldd prog
libdemo.so.1 => ./libdemo.so.1 (0x0000ffff8f870000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff7ff50000)

Ядро Linux было создано под впечатлением от операционной системы MINIX, которая не устраивала Линуса своей ограниченной лицензией.

Ядро 0.0.1 имело размер 62 Кб в сжатом виде и содержало около 10 тысяч строк исходного кода. Кодовая база последних версий насчитывает более 30 млн строк.

По данным исследования, проведённого в 2010 году по заказу Евросоюза, приблизительная стоимость разработки с нуля проекта, аналогичного современному ядру Linux, составила бы более миллиарда долларов США.

Динамика роста кодовой базы ядра Linux:

0.0.1 - сентябрь 1991, 10 тыс. строк;
1.0.0 - март 1994, 176 тыс. строк;
1.2.0 - март 1995, 311 тыс. строк;
2.0.0 - июнь 1996, 778 тыс. строк;
2.2.0 - январь 1999, 1.8 млн. строк;
2.4.0 - январь 2001, 3.4 млн. строк;
2.6.0 - декабрь 2003, 5.9 млн. строк;
2.6.28 - декабрь 2008, 10.2 млн. строк;
2.6.35 - август 2010, 13.4 млн. строк;
3.0 - август 2011, 14.6 млн. строк.
3.5 - июль 2012, 15.5 млн. строк.
3.10 - июль 2013, 15.8 млн. строк;
3.16 - август 2014, 17.5 млн. строк;
4.1 - июнь 2015, 19.5 млн. строк;
4.7 - июль 2016, 21.7 млн. строк;
4.12 - июль 2017, 24.1 млн. строк;
4.18 - август 2018, 25.3 млн. строк;
5.2 - июль 2019, 26.55 млн. строк;
5.8 - август 2020, 28.4 млн. строк;
5.13 - июнь 2021, 29.2 млн. строк;
5.19 - август 2022, 30.5 млн. строк;

Утилиты командной строки: top и htop

Команды необходимы для мониторинга производительности системы (Linux). Их использование полезно для анализа процессов и определения того, сколько CPU тратится на их выполнение, какое потребление оперативной памяти и т.д.

До знакомства с более продвинутыми средствами профилирования, сам использовал htop для обнаружения утечек памяти и узких мест программы, где потребление CPU зашкаливало 🔥

Их основные отличия:

Доступность
• top: Является предустановленным для болишинства UNIX систем.
• htop: Требует ручной установки (доступен в большинстве стандартных репозиториев).

Интерфейс
• top: Текстовый интерфейс с ограниченными возможностями навигации.
• htop: Интерактивный интерфейс с возможностью использования мыши, прокрутки и сортировки.

Информация о системе
• top: Отображает основную информацию о системе - использование ЦП, памяти, своп и процессов.
• htop: Предоставляет более подробную информацию, включая использование диска, сетевой трафик, температуру ЦП, использование его ядер и многое другое.

Управление процессами
• top: Позволяет убивать процессы, изменять их приоритет и просматривать подробную информацию.
• htop: Предлагает более расширенные возможности управления процессами, такие как древовидный вид, фильтрация и поиск.

Настраиваемость
• top: Имеет ограниченные возможности настройки.
• htop: Высоко настраиваемый, позволяет изменять цвета, столбцы и горячие клавиши.

Другие функции
• top: Может отображать графики использования ресурсов.
• htop: Имеет встроенный просмотрщик файлов, монитор сети и другие полезные функции.

Ресурсоемкость
• top: Более легкий и потребляет меньше ресурсов.
• htop: Более ресурсоемкий, но предлагает расширенный набор функций.

Бонус, если вы все еще используете top: для того, чтобы преобразить его внешний вид и вывести дополнительную информацию, можно воспользоваться последовательным вводом (1, z, c, m) 👨‍💻

Pluggable Authentication Modules (PAM) 🔒

Как-то в статье про окружение рабочего стола я разбирал компонент, который использует PAM для аутинтификации пользователя в системе, имя ему "Дисплейный менеджер".

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

Существуют библиотеки PAM, позволяющие выполнять аутентификацию через: локальные пароли, LDAP или считыватели отпечатков пальцев 👍

Как было раньше: желая войти в систему, пользователь был вынужден пообщаться с программой-охранником, гордо именуемой login. Она спрашивала имя, затем шифровала пароль известным алгоритмом и сверяла получивуюся абракадабру с записью в файле /etc/passwd. Если все совпадало, то вход в систему был разрешен.

Через некоторое время, наученные горьким опытом, системы перестали хранить зашифрованные пароли в файле /etc/passwd, открытом на всеобщее обозрение, и переместили эту интимную информацию в файл /etc/shadow, читать который дозволено было только обладателям прав суперпользователя. Программа login была переписана заново: теперь она умела читать из нового файла и шифровать данные по более серьезному алгоритму.

Неизвестно, сколько еще раз пришлось бы переписывать эту программу, если бы не пришла кому-то в голову мысль вынести механизм аутентификации в отдельную систему. Данная разработка получила название PAM.

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

Статические библиотеки ❗️

Статические библиотеки были первым видом библиотечных файлов, доступных в UNIX системах.

Они позволяют объединить набор часто используемых объектных файлов и использовать их для сборки различных программ ⚙️

Статическая библиотека, по сути, является обычным файлом, содержащим копии всех, помещенных в него, объектных файлов.

В библиотеке также хранятся атрибуты для каждого объекта: права доступа, время последнего изменения, идентификаторы пользователя и группы.

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

Таким образом, программа, скомпонованная со статической библиотекой, содержит копии всех объектных модулей, которые были включены в нее компоновщиком, что может приводить к избыточности и ряду неудобств 🥸

Торвальдс посоветовал Кису Куку (Kees Cook) из Google быть решением, а не проблемой в работе с кодом и мейнтейнерами ядра Linux + перестать плодить неразумные жалобы на код компилятора.

Кук вместе с другими экспертами Google работает над выяснением того, как лучше справляться с неожиданными ошибками арифметического переполнения в исходном коде C ядра Linux. ✖️

Он надеется увидеть систематический способ, позволяющий ядру Linux справляться с такими арифметическими проблемами переполнения/недополнения/зацикливания. ⌛️

Среди первоначальных идей — лучше использовать санитайзеры на основе компилятора или возможности языка C для перегрузки операторов без искажения имён.

Сможет ли дека вывести линукс в массы❓

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

Появление SteamDeck показало, что Valve не особо хочет подвязываться к Windows - в идеале, должна быть абсолютно открытая и дицентрализованная ОС, на которой можно будет спокойно запускать игры и не переживать о том, что Microsoft что-нибудь придумают и пользователи спустятся на уровень xbox и playstation. В общем, сейчас доходы Valve немало зависят от имиджовой работы Microsoft.

Компания постепенно будет пушить создание нативных Linux портов и разработку драйверов для лучшей поддержки игровой периферии и последних нововведений железа. Как результат: Nvidia начала активнее обновлять драйвера + появилась поддержка некоторых античит систем.

Результат папуляризации виден уже сегодня, но для лучшего эффекта Valve следует:

1. Сделать их ОС полноценно подходящей для десктоп задач (расширить список flatpak приложений, доработать kde-plasma, добавить больше пользовательского софта)

2. Доработать поддержку старого/нового железа

3. Зафорсить игровые компании выпускать ноутбуки/пк со SteamOS на борту

В общем, перспективы есть, нужно работать 👨‍💻

В продолжении разбора файловой системы, рассмотрим ссылки 🔗

Ссылки бывают 2 типов: жесткие, символические

Жесткие: имеют ID, равный элементу, на который ссылаются. Это означает то, что один и тот же файл (структура inodes) может иметь несколько имен.

Не содержат отдельного поля в таблице индексных дескрипторов -> при создании жесткой ссылки, счетчик ссылок для файла увеличивается 🔼

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

Когда счетчик ссылок = 0, запись в таблице исчезает -> данные для файла затираются 🤪

Хммм, а можно создать жесткую ссылку на каталог? 🤔

Нет! Это предотвращает цикличную зависимость в файловой системе 🚫

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

При создании ссылки, счетчик для файла останется неизменным.

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

Две особенности отличают директории от обычных файлов:

1. Для каталога указывается другой тип файла в записи индексного дескриптора ✉️

2. Блок данных, на который указывает соответствующее поле в таблице inodes, содержит названия файлов/директорий и индексы, по которым происходит поиск элементов в таблице 🔍

Если блок с данными файла содержит внутреннюю его информацию, то блок с данными директории, по сути, является таблицей с полями “имя дочернего элемента / id" в таблице индексного дескриптора 🔗

Ремарка для программистов:

Несмотря на то, что процесс может открыть каталог, он не может применять системные вызовы read и write для того, чтобы изменить данные по дескриптору 🔒

LinuxCamp | DevOps pinned «Habr: Все про композитинг в X11 | Linux 🐧 1. Разбор графического стека Linux 2. Разбор графического стека Linux (рус) 2. Статья про композитинг 3. Статья про композитинг 4. Как обработать и сохранить графическое представоение окна после перенаправления?…»

Habr: Все про композитинг в X11 | Linux 🐧

1. Разбор графического стека Linux
2. Разбор графического стека Linux (рус)
2. Статья про композитинг
3. Статья про композитинг
4. Как обработать и сохранить графическое представоение окна после перенаправления?
5. Статья про композитинг, автором которой является разработчик kwin
6. Статья про композитинг
7. Исходный код awesomewn (ссылается на файл, который контролирует root и его фон)
8. Описание функционала различных компонентов рендера X11 (Drawable, Pixmap, Image, Visual)
9. Что из себя представляет фон рабочего стола + как его выставить и получить?
10. Программная реализация небольшой кодовой базы, на которой основывается композитинг
11. Для чего нужны DDX драйвера, когда Xorg использует DRM?
12. Документация расширения XComposite
13. Как X11 использует графическое ускорение?
14. Книга про разработку графики, неплохо растолковывает то, как устроена оконная система X
15. Что такое DRI?
16. Что такое DRM?
17. Что такое framebuffer?
18. Что такое двойная буферизация?
19. Что такое EGL/GLX?
20. Что такое OpenGL контекст?

Кто что слышал про Nobara Linux?

Очень интересная сборка, которая как бы должна давать в лоб всем хейтерам “домашнего” Linux, но пока этого сделать не может из-за немалого количества багов. ⚙️

Дистрибутив разработан создателем Proton GE - пропатченной и доработанной версии утилиты Proton для запуска steam игр на линухе. 🎮

Nobara предоставляет широкий спектр приложений (в том числе, с кастомными патчами), зависимостей и драйверов “из коробки”. 🛠

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

Достаточно неплохо вас может познакомить с этим дистр вот это видео

Если бы меня спросили “Какую книгу стоит прочесть для того, чтобы приблизиться к абсолютному пониманию Linux?”, ответ был бы однозначным:

“Linux API Исчерпывающее руководство” - Майкл Керриск 📕

Книга не только знакомит читателя с различными подсистемами операционки, но и глубоко их разбирает, приводит примеры реализации различных модулей на языке C (нативном для ядра и множества системных программ) 👨‍💻

Материал очень грамотно подается: все начинается с подробного разжевывания базовых терминов (kernel, linux, unix, posix, gnu) и уходит вплоть до реализации TCP протокола и файловой системы.

Хардкорные сишники/плюсовики (бэкендеры) точно оценят книгу, т.к довольно глубоко объясняются принципы сетевого взаимодействия на сокетах и мультиплексирование ввода/вывода (poll, epoll, select) 🤘

Habr: Компоненты среды рабочего стола | Linux 🐧

1. Принцип работы PAM системы аутентификации
2. Туториал по созданию дисплей менеджера
3. Исходный код дисплей менеджера SDDM
4. Исходный код DM с исключительно базовым функционалом
5. Принцип коммуникации X11 клиента и оконного менеджера
6. Исходный код стартап модулей окружения kde-plasma (startkde)
7. Как dm понимает, какое окружение запустить?
8. Исходный код оконного менеджера dwm
9. Как работают оконные менеджеры в X11 и как написать такой?
10. Что такое оконный менеджер?
11. Что такое gnome-shell?
12. Общая информация про оконные менеджеры