Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

В итоге получилась схема, при которой все сервисы доступны по красивым доменным именам с HTTPS, но абсолютно невидимы для внешнего интернета.

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

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

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

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

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

Об этом Миллер написал на своем личном сайте, отметив, что уже более 30 лет остается фактически единственным мейнтейнером одного из ключевых инструментов Unix- и Linux-систем.

Что произошло

До февраля 2024 года разработку sudo спонсировала компания Quest Software (позже — One Identity). После завершения сотрудничества и ухода Миллера из компании, финансирование прекратилось. С тех пор поддержка проекта ведется без стабильного источника дохода.

При этом разработка sudo не останавливалась: за последние два года выходили обновления и исправления, включая патчи для критических уязвимостей. Однако, по словам Миллера, из-за нехватки времени и ресурсов работа над проектом заметно замедлилась.

Почему это проблема

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

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

Именно из-за регулярных проблем с безопасностью в экосистеме появился sudo-rs — новая реализация утилиты на Rust, ориентированная на безопасную память. В Ubuntu 25.10 она уже используется по умолчанию.

Что будет дальше

Миллер подчеркивает, что не планирует бросать sudo, но и не видит очевидного преемника. После истории с закладкой в xz-utils, он с осторожностью относится к передаче проекта сторонним разработчикам.

При этом он считает, что в долгосрочной перспективе именно sudo-rs станет основной версией инструмента. Он уже даже сотрудничает с командой этого проекта.

Но если в UNIX это скорее философия с оговорками, то в PatchworkOS идея доведена почти до абсолюта. Здесь файлами считаются не только данные, но и процессы, события, таймеры и даже взаимодействие с ядром.

Проект носит исследовательский характер и не претендует на роль универсальной ОС для повседневного использования.

Как работает «все — файл» в PatchworkOS

В PatchworkOS файловая система — это главный интерфейс ко всему, что происходит в системе.

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

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

Сам автор проекта описывает PatchworkOS как систему, где файловая и процессная модели слиты воедино, а граница между «данными» и «поведением» намеренно размыта.

Минимум абстракций и максимум прозрачности

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

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

Норберг отдельно отмечает, что его операционка — это не Linux-дистрибутив и не попытка конкурировать с существующими ОС.

Ограничения и честные предупреждения

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

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

Если находка подтвердится, перед нами — одна из старейших копий легендарной операционной системы.

Как нашли ленту

Ленту обнаружил профессор Роберт Риччи во время уборки в школе вычислительной техники Университета Юты.

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

Чтобы не повредить артефакт, Риччи передал его в Computer History Museum в Калифорнии. И там, прямо сейчас, ленту осторожно побитово «снимают», не запуская на обычных магнитофонах. Это нужно для того, чтобы не стереть данные.

Почему это важно

Unix V4 — одна из первых версий, переписанных на языке C. Именно этот шаг сделал систему переносимой между разными машинами. И уже из этого решения выросли Linux, macOS и Android, а архитектура Unix до сих пор лежит в основе большинства современных ОС.

До последнего считалось, что оригинальная V4 утеряна — в архивах сохранились лишь обрывки кода и фрагменты мануалов.

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

Проблема «цифровой археологии»

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

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

Почему Unix из Юты — особенный

В 1970-х Юта была одним из ключевых узлов ARPANET и первых университетов, получивших Unix по исследовательской лицензии Bell Labs. Местные студенты и инженеры активно модифицировали систему.

Именно из таких экспериментов, например, позже выросли BSD и многие современные утилиты.

Что дальше

Эксперты из Computer History Museum планируют оцифровать ленту и, при возможности, опубликовать исходники для исследователей.

Если восстановление удастся, это будет самое значимое возвращение утерянного программного кода за последние десятилетия — своеобразная «цифровая археология» уровня открытия древнего манускрипта.

Первые две части лежат здесь: рабочее место/облако и Fedora Core/mise.

Начало проекта и утилита make

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

Первый — классический пайплайн — это утилита make. Обычно она используется для сборки программ из исходного кода. На самом деле make хорошо подходит для решения сразу нескольких задач.

• Первая задача — отслеживание зависимостей одних файлов от других, например, при изменении сервиса пересобрать только соответствующий контейнер.
• Вторая задача, легко реализуемая через make — сборка в один файл много команд или скриптов, чтобы удобно их организовать. Как правило, сборка образа, его загрузка в репо, удаление временных файлов и прочее делается несколькими рутинными командами. Точно так же можно поместить в Makefile команды запуска сервисов и тестирование приложения локально.
• Если эти этапы прошли успешно, можно выполнить коммит кода в репо проекта, сделать деплой в dev или stage environment. В github actions это называется jobs и steps. В make такая группа команд называется целью, она указывается параметром при вызове.

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

Разбираемся на практике

Возьмём для примера проект с прокси сервером traefik и бэкендом на golang из репозитария awesome-pods. Этот репо задуман как форк замечательного проекта awesome-compose, в котором собраны конфиги docker compose для 41 самого популярного сервиса. Я же пытаюсь сделать что-то похожее для манифестов podman. Приглашаю к сотрудничеству начинающих девопс — сможете поучаствовать в открытом проекте, заработать почётные гитхаб-бейджи и улучшить своё резюме. Подробнее — здесь.

Мой проект в интересном положении: сделаны манифесты для нескольких сервисов, опробованы описанные выше подходы для миграции конфигов compose.yaml в манифесты kube.yaml. Но захотелось большего: а почему бы не сделать сразу пайплайны для тестирования, коммита в апстрим, деплоя и прочее. Зайдём в каталог traefik-golang и создадим пару мейк-файлов. Для начала сделаем всё это локально, начнём с make_compose:

Этот файл уже в истории, равно как и соответствующий README.md, привожу его для примера. Так как я делаю конфиги сразу для двух платформ — docker и podman, для включения соответствующего Makefile’а нужно сделать линк на него: ln -s make_compose Makefile.

Отлично, основную идею обсудили, идём дальше. В docker’е есть замечательная опция context, позволяющая работать с любыми серверами, где настроен доступ. В нашем случае список контекстов выглядит так:

Здесь я использовал простейший хак — сделал копию дефолтного контекста с именем localhost. Теперь мы можем сделать наш пайплайн способным на удалённый деплой. Достаточно прописать в /etc/hosts имя и адрес нашего dev сервера. Вот новая версия make_compose:

Поясню немного подробнее.

• Самая первая строка — стандартное объявление списка целей.
• Строки 2-4 задают дефолтное значение переменной, если оно не задано в текущем env.
• В хелп — строки 5-10 — добавлено предупреждение о текущем контексте, он задаётся в глобальной переменной, например, export DKR_CONTEXT=localhost для локального контекста.
• Также добавлена цель commit в репо — строки 17-21 — после выполнения цели test.
• Test — строки 31-32 — в свою очередь, выполняется для текущего контекста, см. хак #1. Имя контекста должно совпадать с именем хоста нашего dev-сервера.
• Добавлена также цель clean: очистка старых образов с локальном репо,и зависимости в цель up. Здесь убеждаемся, что образ пересобран и старые контейнеры остановлены.

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

В строке 5 определяются зависимости: target back соберёт исполняемый файл только в том случае, если код main.go или сам make_pods новее уже собранного бинарника.

Строка 6 удаляет backend контейнер с едва заметным знаком минус -, чтобы игнорировать ошибку, если контейнер с именем backend не существует.

Строки 7–10 создают контейнер с именем backend из пустого (scratch) контейнера — команды buildah следуют обычным командам Dockerfile, но в нижнем регистре: FROM -> from, COPY -> copy, RUN -> run, ENTRYPOINT -> config –entrypoint и т. д. Здесь вы видите основное отличие от традиционного docker buildx подхода — вы работаете в двух контекстах одновременно: в локальном контексте, используя установленный компилятор go, и в контексте контейнера, копируя файлы в/из контейнера, запуская команды внутри контейнера и т. д. Другая новая возможность buildah — вы можете собирать образ шаг за шагом, то есть отлаживать процесс сборки.

Строка 8 компилирует main.go в исполняемый файл back с соответствующими флагами.

Строка 11 создаёт из контейнера новый образ (image) с тегом backend:latest.

Цель up — строка 16 — зависит от цели down — строка 14, — то есть она сначала останавливает pod и удаляет контейнеры, если они всё ещё запущены, затем запускает новый под.

Цель down в строке 15 подставляет глобальную переменную $XDG_RUNTIME_DIR из env пользователя в kube.yaml, используемый далее в podman kube командах, принимая новый манифест со стандартного ввода. Это также специфика podman — он работает полностью в пространстве пользователя, контейнеры взаимодействуют через собственный podman.sock. Таким образом, делаем пайплайн независимым от UID.

В подмане есть фунциональность наподобие docker context, под другим именем, в подкоманде system connection:

Первым в списке стоит настроенная в прошлой статье ВМ. Пока искал правильные опции для создания коннекшена (aka контекст в докере), столкнулся с подсказкой от подмана — «создайте сначала машину», а именно:

Выполнил эти рекомендации, подман выкачал, настроил и добавил два новых коннекшена для новой ВМ. Какой же меня ждал сюрприз, когда я стал смотреть, что же это за machine. Во-первых, в моём HOME появились новые файлы и каталоги:

Во-вторых, это полноценная ВМ fedora coreos:

Конечно, приятно, что моё мнение совпало с мнением авторов подмана, точнее, со стратегией RedHat — fedora coreos наиболее подходящая система для контейнерных приложений. С другой стороны, ВМ в подмане крутится полностью внутри пространства пользователя. У меня уже настроена почти такая же для удалённой работы всей команды разрабов. Решено: останавливаем новую виртуалку и правим мейкфайл для подмана по образцу компоуза, делаем пайплайн для деплоя и локально, и на удалённый дев-сервер.

Но прежде нам понадобится ещё один хак #2. Если в случае докера переключение контекста можно было сделать любой переменной, то для подмана между локальным соединением через сокет и удалённым, через uri:ssh, имя переменной фиксировано CONTAINER_HOST. Вот как выглядит пайплайн make_pods.v1, настроенный и для локальной сборки, и для деплоя в наш дев-сервер:

По большей части цели мейкфайла остались теми же, но для удалённого деплоя настраиваем переменную export CONTAINER_HOST=ssh://dev@fc42dev:22/run/user/1001/podman/podman.sock — берём её из коннекшена, она служит переключателем между локальным и удалённым контекстом. Для локального контекста эту переменную надо удалить: unset CONTAINER_HOST. Команды в строках 19, 21 и 23 — это обычные команды шелла, они также меняются на локальное либо удалённое исполнение, переопределяются на основе этой же переменной CONTAINER_HOST.

Как заметил внимательный читатель, в цели back исчезла сборка контейнера утилитой buildah. Как и для docker compose, используется возможность самого подмана создавать образы на основе Containerfile, он же Dockerfile, эти названия синонимичны. Это намёк: пора отвыкать от слова докер, контейнеры уже давно стали основой облачных вычислений, для них созданы сотни приложений, например, CNCF и общепризнанные стандарты.

Принципиальный вопрос о контейнерах

Основное их преимущество — новый способ доставки приложений в облака, решение проблем с зависимостями, версиями библиотек, фреймворков и проч. Сборка контейнеров в контейнерах — побочный эффект облачных сервисов Github, Gitlab и других, с одной стороны, и ограничения Docker — с другой. Он не умеет, в отличие от подмана, точнее, от его сопутствующей утилиты buildah, выполнять билд и создавать образ, используя локальное окружение.

Основная проблема сборки образа внутри контейнера — неэффективное использование кэша. Да, появились возможности как-то сохранять объемные загрузки внешних библиотек, модулей: это опции --mount=type=cache для некоторых языков. Но, во-первых, эти возможности используются далеко не всегда. Во-вторых, опции для кэширования отличаются в podman и buildah, см. podman-build(1), придётся делать отдельный Containerfile. В-третьих, эффект от такого кэширования минимален. Предлагаю замерить время сборки, сделав ещё одну, третью версию пайплайна. Сначала соберём команды для buildah в отдельный файл:

и поправим пару строк в пайплайне:

Уточню условия нашего эксперимента — мы настроили одинаковую среду разработки с помощью утилиты mise (предыдущая статья) на нашем дев-сервере и у каждого из разрабов команды. Репозитарий git использует этот же дев-сервер, доступ к репо и серверу по ключу, парольный доступ закрыт. Пайплайны настроены как для локальной сборки, так и на дев-сервере. Перед запуском 3-й версии пайплайна на дев-сервере нужно сделать коммит изменений в репо — buildah не знает о коннекшенах, работает с кодом в текущем каталоге (строка 1): после логина на сервер переключается в корень проекта. Предварительно выкачиваем образ компилятора go для сборки в контейнере — это вполне честно, мы же выкачали и настроили компилятор golang заранее. Замеряем:

Мы получили 10+-кратный выигрыш по времени сборки образа для подмана. Абсолютные времена не важны, также не влияет, запускали мы сборку локально или на дев-сервере — мы сравниваем только билд в контейнере и в настроенном локальном окружении. Третье измеренное время — сборка в Docker. Он умеет собирать только в контейнере, для него настроили кэширование в Containerfile:

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

Ещё замечание: конечно, образы, собираемые buildah, совместимы с Docker, их можно использовать в конфигах compose.yaml. Но для этого надо настроить репозиторий образов и сначала загрузить образ в него. Локальные репозитории отличаются: Docker использует общий репо для всех пользователей — Docker Root Dir: /var/lib/docker, а в подмане всё хранится в домашнем каталоге пользователя — graphRoot: /home/$USER/.local/share/containers/storage.

Как я предположил в самом начале, мы попробовали вариант с гипотетической идеальной командой разрабов, работающей в Линукс и умеющей в make. А как быть обычному девопсу с разношерстой командой, где кто-то сидит на Винде, а кто-то ни за что не откажется от привычного Макбука на M4? Есть вариант и для этого случая. Пусть они пишут код и тестируют его как им нравится, а в нашем репо на дев-сервере мы сделаем хак #3, а именно git hook и bare репозиторий — githooks(5), выполняющий наши цели сборки и старта приложения при коммите в репо.

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

1. Заходим под юзером dev на сервер, создадим пустой каталог, например, mkdir -pv ~/bare/t0. Это станет новым GIT_DIR, зайдём в него и выполним cd ~/bare/t0;git init --bare.
2. Видим, что файлы, обычно спрятанные в каталоге .git, лежат прямо в корне. Сделаем дополнительно каталог для логов mkdir logs. Переходим в каталог hooks и создаём файл, где укажем команды выполнения при каждом изменении в репо.

Закомментированные строки 3, 8, 9 полезны при отладке пайплайна. Строки 4 и 5 задают, что есть, собственно, репозиторий, переменная GIT_DIR и переменная WORK_TREE (куда будут записываться файлы проекта). В цикле от строки 6 до 14 читаются и обрабатываются три переменные, с которыми гит вызывает этот хук. Строка 11 принимает все изменения в репо и обновляет WORK_TREE — всё то, что гит обычно делает в общем каталоге, как видим, в bare репо они разные. Далее, в 12 строим имя лога и строка 13 — собственно, пайплайн.

1. Идём в каталог, где расположен репо проекта. Без страха и сожаления удаляем старый и создаём новый под тем же именем: cd ~/src;rm -rf traefik-golang;mkdir traefik-golang.
2. Завершаем сессию на дев-сервере, возвращаемся на рабочий комп и заходим в репо проекта. Конечно, репо цел, клоны репо не так просто уничтожить, пока есть хотя бы одна копия. Теперь смотрим старые настройки git remote -v и удаляем их git remote remove fc42dev в моём случае. Создаём новый remote, указывая новый гит bare репо: git remote add bare.t0 dev@fc42dev:~/bare/t0. Это также нужно сделать всем разрабам в их локальных копиях.
3. Проверяем результат. Возможно, нужно сделать новый комит и push в новый remote. Стоит посмотреть подробнее, как изменился репо проекта на сервере: проверить логи в ~/bare/t0/logs, сравнить конфиги обычного репо проекта и на сервере, проверить, какие команды перестали работать в серверном репо. Например, в WORK_TREE не работают команды гит status; branch; commit; log. То есть наш хак #3 с git --bare не только позволил делать деплой на сервере, но также защитил репо от локальных изменений, а серверный репо всегда в чистоте и порядке. Можно редактировать код, но закомитить его только через обычный репо. Изменения на сервере удалятся после любого коммита.

Надеюсь, мне удалось показать, что пайплайны можно делать на основе древней забытой утилиты make. В следующей статье разберём, как можно добавить в наш скромный дев-сервер нечто похожее на монстров гит-сервисов, Gitlab и Github, создавать пайплайны, совместимые с github Actions, предоставить команде разрабов привычный интерфейс репо в браузере.

В целом структуру файловых систем (ФС) в Линукс определяет унифицированный стандарт FHS (Filesystem Hierarchy Standard), однако есть множество нюансов, в которых стоит разобраться, прежде чем работать с этой ОС.

Выясним, что собой представляет файловые системы, доступные в Linux, какие директории и типы файлов в них содержатся, как управлять ФС и что такое монтирование в Линуксе.

Общий обзор файловой системы Linux

Еще на стадии установки Linux предоставляет пользователю выбор файловой системы — разные типы ФС уже встроены в ядро ОС. Выбирать нужно в соответствии с требованиями и задачами владельца устройства, поскольку у каждой системы свои функциональные возможности. В Windows опции выбора нет — в этом одно из принципиальных отличий этой ОС от Linux.

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

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

Правильный выбор файловой системы влияет на следующие показатели:

• скорость выполняемых операций;
• сохранность файлов;
• скорость записи данных;
• размер и другие параметры файлов.

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

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

В Линукс ФС представляет собой пространство, разделенное на блоки определенных размеров, кратных 1024, 2048, 4096 байт и т.д. Вместимость блоков известна заранее и ограничена максимальным объемом ФС.

Обмен данными реализуется двумя способами:

• С помощью VHS — виртуальной файловой системы. В таких системах ядро и установленные приложения работают совместно без учета особенностей конкретных ФС;
• С помощью драйверов, отвечающих за обмен данными между железом и софтом.

Список систем, поддерживаемых ядром, находится в файле /proc/filesystems. Наиболее востребованные ФС мы подробно рассмотрим в одном из следующих разделов.

Структура ФС и каталога

В Linux файловая система отвечает также за иерархию, то есть порядок распределения файлов. Структура подобна дереву — в основе лежит корневой каталог root directory, от которого отходят «ветви».

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

В Linux используется несколько типов файлов. Часть из них повторяет аналогичные пакеты в Windows — это текстовые документы, медиа различного формата, музыка. Принципиальные различия начинаются с каталогов, представленных отдельными типами файлов.

Жесткие диски в такой структуре относятся в блочным устройствам, принтеры — к символьным, в отдельной группе — символические ссылки, о которых расскажем позднее. В типы файлов входят каналы взаимодействия между процессами и гнезда центрального процессора. Тип файла можно определить через команду ls.

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

Помимо единственного корневого раздела root, присутствуют подкаталоги, к которым привязаны соответствующие каталоги. Типовая структура первых двух уровней выглядит так:

├── bin -> usr/bin

├── boot

│ ├── grub

│ └── lost+found

├── dev

│ ├── block

│ └── …

├── etc

│ ├── …

│ ├── update-manager

│ ├── update-motd.d

│ └── xdg

├── home

├── lib -> usr/lib

├── lib32 -> usr/lib32

├── lib64 -> usr/lib64

├── libx32 -> usr/libx32

├── lost+found

├── media

├── mnt

├── opt

├── proc

│ ├── …

│ └── tty

├── root

├── run

│ └── …

├── sbin -> usr/sbin

├── srv

├── sys

├── tmp

│ └── …

├── usr

└── var

Каждый файл в ФС Линукса имеет конкретный индекс Inode. У одного файла в такой структуре может быть несколько имен, т.е. путей. В структуре системы файлы могут различаться, но на жестком диске им соответствует один файл. Такое свойство называют перекрестной иерархичностью — ветви дерева пересекаются.

Inode — индексный дескриптор, который используется в UNIX-системах. В нем хранятся все мета-данные о файле: владелец, время последнего обращения, размер, другая информация.

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

В числе других особенностей Linux — ссылки двух типов:

• жесткая ссылка (то есть hard link) — путь файла, заданный командой ls -li;
• символьная ссылка (symbolic link) — файл стандарта UNIX с текстовой строкой, задающей путь к оригинальному файлу.

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

Ключевые директории и их назначение

В Linux директория — фундаментальный элемент системы. Это каталог (папка), где содержатся другие файлы, расположенные согласно иерархии. Отправной точкой, а точнее, базой выступает корневой каталог «/», на котором выстраивается вся система.

В некоторых источниках этот каталог сравнивают с диском С на винде, но это не совсем корректное сравнение — в Линуксе нет буквенных дисков. В Windows дополнительный раздел расположен на диске D, в Линукс это будет отдельная папка с тем же корнем. Иными словами, путь к любому файлу проходит через корень.

Пример. Файл /home/user/alien имеет структуру root -> home -> user -> documents, и никакую другую.

Рассмотрим наиболее востребованные директории и их функции.

Пользовательские файлы /bin и /sbin

В этой директории расположены бинарные исполняемые файлы, которые требуются для загрузки системы и ее работы. Именно здесь вы найдете команды ls, cp, grep, mv, ping и прочие утилиты, доступные каждому юзеру. В /usr/bin хранятся и такие приложения, как браузер Chrome, Firefox и другие.

В каталоге /sbin, который имеет схожую конфигурацию, содержатся важные исполняемые файлы для системного администрирования. Это iptables, reboot, fdisk и т.д..

Пользовательские данные /home (домашняя папка)

В этом каталоге хранится домашняя папка с личными файлами и настройками. Например, если ваше имя юзера — denis, у вас будет домашняя папка /home/denis. Сюда записываются, например, скачанные файлы. Если пользователей несколько, они будут записывать файлы в свои папки. Для изменения других системных файлов потребуются права root.

Конфигурационные файлы /etc

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

Файлы устройств /dev и системные файлы /proc

В директории /dev хранятся интерфейсы системных и периферийных устройств — дисков, принтеров, динамиков и прочих. В Линуксе устройства представлены в виде файлов. Стоит понимать, что это не совсем файлы в том виде, к которому мы привыкли. Псевдоустройства из этого каталога — это, например, генераторы случайных чисел /dev/random.

Файлы ядра и процессов содержатся в каталоге /proc. В нем, как и в /dev, нет стандартных файлов, а есть специфические области данных о системах и процессах. Здесь есть информация о процессоре /proc/cpuinfo; сведения о памяти, используемой системой — /proc/meminfo; время — /proc/uptime. Тут же содержится информация о системных ресурсах.

Переменные (изменяемые) данные /var

В этой директории лежат данные, которые в процессе работы системы постоянно меняются. Сюда относятся логи, кэши, системные журналы, почтовые очереди и прочие файлы, создаваемые программами.

Это записываемая директория, которая в стандартном режиме доступна только для чтения. Логи содержатся в /var/log, базы данных в /var/lib, файлы для перезагрузки в /var/tmp.

Статические файлы для загрузки /boot

Это важные файлы для загрузки ОС, в том числе ядра Линукс. Запуск системы без этой папки проблематичен. При этом файлы конфигурации загрузчика находятся в другой папке — /etc, о которой мы писали выше.

Общие файлы библиотеки /lib

В директории /lib находятся файлы, которые обеспечивают работу системных программ и ядра. Эти данные приложения и бинарные файлы /bin и /sbin используют для выполнения заданных функций.

Съемный носитель /media

В этом директории монтируются съемные носители. К примеру, когда вы используете компакт-диск или флешку, автоматически создается каталог. Юзеры получают полный доступ к содержимому носителей.

Временные файлы /tmp

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

Восстановленные данные /lost+found

В любой ФС Linux есть такая директория. Если в системе случится сбой, при следующей загрузке произойдет автоматическая проверка, и любые обнаруженные поврежденные файлы отправятся в каталог /lost+found, чтобы пользователь при необходимости смог восстановить данные.

Файлы состояния приложений /run

Относительно новая директория в Линукс. Здесь хранятся необходимые приложениям временные файлы — сокеты, идентификаторы процессов и другие. В отличие от каталога /tmp данные в /run нельзя удалить.

Типы файлов в Linux

Линукс подчиняется концепции «Всё есть файл», то есть работа с системой — это по сути взаимодействие с файлами. Применяются разные файлы, используемые как для стандартных данных, так и для устройств.

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

Рассмотрим типы файлов, которые используются в Linux:

• Обычные (regular). Это стандартные файлы, используемые чаще других — данные, текст, исходный код, медиа и все остальное;
• Файлы устройств. Сюда входят символьные и блочные файлы (char и block devices), представляющие внешние устройства — принтеры, жесткий диск и другие;
• Именованные каналы. Файлы named pipes требуются для взаимодействия между процессами и передачи данных;
• Ссылки. Используется два типа ссылок. Символические (так называемые симлинки) — работают как ярлыки для указания других каталогов и файлов; жесткие — отвечают за альтернативные способы доступа к физическим данным на диске и выступают дубликатами файлов, но без их фактического дублирования;
• Каталоги. Папки со ссылками на файлы и другие папки. Отвечают за организацию данных и их распределение по категориям, упрощают доступ к различным разделам;
• Сокеты. Файлы, предназначенные для обмена данными при выполнении рабочих задач. Используются как внутри системы, так и при взаимодействии устройств друг с другом. По сути, это своего рода почтовые службы, с помощью которых программы пересылают информацию друг другу;
• Двери. Еще один механизм, ответственный за взаимодействие между процессами.

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

Управление файловой системой

Через консоль управления (терминал) в Linux доступен целый арсенал для работы с директориями и файлами.

Основные команды управления:

• Is. Просмотр содержимого папки и навигация. При использовании с различными опциями возможности расширяются, например, команда ls -l создает подробный список;
• cd. Путь к папке — меняет текущую директорию на указанную пользователем;
• pwd. Обозначает текущие местоположение юзера в структуре каталогов;
• mkdir. Используется для создания новой папки с присвоением ей имени;
• cp. Копирует файлы из исходной папки в целевую;
• mv. Перемещает или переименовывает каталоги и файлы;
• rm. Удаляет указанные файлы;
• cat. Выводит содержимое указанного файла в окно панели управления;
• less. Используется для постраничного пролистывания файла;
• touch. Создает новый пустой файл (с новым именем);
• ln -s. Генерирует символьную ссылку, указывающую на выбранный каталог или файл;
• which. Демонстрирует пошаговый путь к исполняемым файлам;
• nano. Используется для текстовой редактуры файла;
• locate. Применяется для поиска файлов по заданным шаблонам.

Указанные выше команды формируют основу для взаимодействия с ФС. При необходимости используется более расширенный список.

Монтирование и файловые системы Linux

Монтирование — подключение файловых систем, жестких дисков и внешних носителей, получение доступа к ним, ручное и автоматическое отключение. При загрузке ядро устройства на Linux автоматически монтирует разделы, считывая данные из конфигурации /etc/fstab.

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

Монтирование системы реализуется с помощью команд mount и umount, подготавливающих устройства и точки монтирования. Они реализуют автоматическое подключение ФС. К виртуальной машине подключается диск /dev/sdc, на котором создаются разделы для файловой системы. После создания точки монтирования процесс загрузки ФС запускается.

Какие файловые системы на Linux наиболее востребованные:

• Ext. Первая ФС, разработанная специально для Линукс. Система значительно превзошла предыдущие решения по производительности и функционалу;
• Ext2. Улучшенная версия первой ФС. Повышает надежность, улучшает управление и позволяет работать с большим количеством данных и файлов;
• Ext3. Третье поколение ФС для Линукс. Поддерживает журналирование, что делает работу более стабильной и минимизирует риски потери данных после сбоев системы;
• Ext4. Новейшая версия с повышенной эффективностью и масштабируемостью. Технически более совершенный вариант, упрощающий работу с большим объемом данных;
• JFS. Разработка компании IBM. Эффективно использует ресурсы, отличается высокой производительностью, рассчитана на сильные нагрузки;
• XFS. Высокопроизводительная ФС, разработанная компанией SGI. Подходит для работы с серверами и системами хранения данных;
• ReiserFS. Разработка программиста Ганса Райзера. Главная особенность — возможность при необходимости увеличивать размер блока, тем самым избегая фрагментации;
• Btrfs. Продукт компании Oracle. Обеспечивает гибкость при управлении данными, предоставляет опции оперативной проверки и восстановления файлов, интегрирует разные устройства в единую ФС;
• Swap. Позволяет использовать дисковое пространство как виртуальную память, если физические возможности RAM исчерпаны. Технически этот инструмент нельзя назвать файловой системой, но он обеспечивает широкие возможности для управления данными в Линукс.

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

При этом у пользователя всегда есть свобода выбора — например, между стабильностью линейки Ext и гибкими возможностями файловых систем XFS, JFS. Безграничные возможности выбора отражают дух сообщества Linux, где независимые разработчики постоянно предлагают новые решения, обеспечивая постоянное развитие экосистемы.

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

Так, при компиляции, она превращается в исполняемый файл, полный символов и зависимостей.

Например, команда objdump -x hello показывает, что даже базовая программа содержит множество секций, таблиц символов и метаданных:

Попытка минимализма

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

Это требует непосредственного написания системных вызовов Linux. Например, вызов write можно реализовать напрямую:

Разбор структуры ELF-файла

Статья подробно объясняет структуру ELF (Executable and Linkable Format) — стандартного формата для Unix-систем.

Заголовки ELF, секции и сегменты взаимодействуют друг с другом для создания исполняемого файла.

Например, заголовок ELF содержит ссылки на таблицы символов и разделы, такие как .text (код программы) и .data (данные).

Линкер и оптимизация

Автор также разбирает использование кастомных скриптов линковки для создания минималистичных исполняемых файлов.

Например, с помощью линкера ld можно исключить ненужные зависимости и сократить размер программы.

Выводы

Как оказалось, даже простая программа «Hello, World!» скрывает сложность, связанную с взаимодействием компилятора, линкера и операционной системы.

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

1. Все драйверы содержатся в ядре системы. Обновляется дистрибутив — ядро пересобирается, обновляются или удаляются старые драйверы, и устройство, прекрасно работающее долгие годы, просто «отваливается».
2. Политика некоторых дистрибутивов достаточно жесткая: например, в ядре содержатся только драйвера со свободной лицензией. Поэтому с компонентами от AMD и Intel проблем не возникает, а вот для того, чтобы настроить видеокарту от NVidia, нужно заморочиться.

С мышками, клавиатурами и прочими мелочами, как правило, бед не случается. Управление этими устройствами происходит через стандартные интерфейсы. Туда же можно отнести флэш-накопители, устройства NVMe и даже контроллеры USB и SATA — для них нет специфичных Linux драйверов. Что нельзя сказать про wifi-адаптер: для каждого придётся вручную подбирать необходимое ПО.

https://tproger.ru/articles/v-chyom-linux-luchwe-windows

А это нормально, что ядро Линукса так сильно раздуто драйверами?

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

Для примера, около 380 драйверов будут весить столько же, сколько .txt-файл с первым томом «Войны и мира», или как трехминутный качественный mp3-трек. При этом Unix-системы оставляют возможность перекомпилировать ядро, избавиться от ненужных модулей и сократить его вес почти в 10 раз. Но мы настоятельно не рекомендуем заниматься этим на рабочих машинах, особенно если о такой возможности вы только что узнали.

К тому же, образ Windows тоже содержит огромное количество предустановленных драйверов. Например, для того, чтобы live usb корректно работал на любой машине.

Что не стоит делать в Linux с драйверами

Последнее, к чему советуют прибегать — это скачивать драйверы с сайтов-производителей и вручную запускать их в Unix-системе. На это есть ряд причин, рассмотрим на примере установки драйверов NVidia в Linux:

• драйвер может перезаписать библиотеку с графическим интерфейсом Mesa GL, из-за чего перестанет работать открытый драйвер (если вы работаете со встроенной AMD и дискретной NVidia-картой, то система при обновлении не сможет распознать даже AMD);
• установленный с сайта драйвер не обновится с ядром, его нужно будет переустанавливать вручную;
• в случае, если у вас отвалятся оба драйвера, придётся накатывать обновления через CLI (терминал).

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

Что делать, если что-то не работает в Линукс?

1. Воспользуйтесь встроенным ПО

В Линуксе нет привычного для Windows-пользователей диспетчера устройств. Но можно воспользоваться аналогами, например, «Additional driver» в Ubunta или менеджером пакетов для GNOME в других дистрибутивах. На крайний случай скачать утилиту Inspector.

Посмотрите, какие драйверы уже установлены

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

Если у вас есть название драйвера — то можно воспользоваться командой grep (она помогает фильтровать вывод по ключевому слову).

Например, вы можете ввести lspci | grep NVIDIA, если хотите узнать, установлен ли драйвер NVidia.

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

или, по аналогии,

Если команды dmesg или lscpi вывели нужный вам драйвер, значит, проблема не в нём. А вот если они ничего не дали, значит, драйвер не установлен или не распознаётся. Тут нужно проверить, есть ли драйвер в файловой системе:

и

Тут тоже можно использовать | grep SOME_DRIVER_KEYWORD. Если драйвер распознается этими командами, но не lscpi или dmesg, это означает, что драйвер находится на диске, но не в ядре. В этом случае загрузите модуль с помощью команды modprobe:

Обратитесь к wiki

Если вам нужны проприетарные драйверы, перейдите в документацию вашего дистрибутива или на специальную wiki и найдите, для чего вам нужны драйверы (например, для "nvidia"). Скорее всего, правильному способу это сделать будет посвящена целая страница. Вот для примера вики по Astra Linux и установке NVidia-драйверов.

https://tproger.ru/books/linux

Заключение

Проблема с драйверами в Линуксе достаточно масштабная: при очередном обновление ядра устройства могут внезапно выйти из строя, начать греться или наоборот, лучше работать. Хорошая новость заключается в том, что по каждому популярному оборудованию можно найти репозитории с проприетарными драйверами, а также пошаговую инструкцию, как их накатить. Если вы всё же нацелены перейти на Linux и хотите выбрать хороший дистрибутив, то наш материал может помочь.

Ниже — транскрибация ролика, дополненная ссылками.

Шесть лет назад я, Виндертон, будучи в состоянии аффекта, выкладываю вот этот вот ролик, который посмотрело уже больше 100 тысяч человек: «Техническая литература для программистов». Чтобы сэкономить вам 10 минут вашего времени, там были показаны вот эти вот книги.

Вопросов нет. Кнут — это классный автор с крутыми материалами. На кто его потянется со всей этой математикой, если даже вот эти челы не тянут, а конкретно тот, что с бородой — Шон Магресс. Тадембаум — та же самая история. Классный материал, но настолько сложное задание, что порой вгоняет в депрессию. Корман заставляет писать вас вообще деревья с нуля без примеров.

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

Ну а мы разбиваем видео на три части:

1. Введение в программирование и ядро computer science.
2. Моя библиотека. GameDev, прочее.
3. Языки программирования.

Введение и основы computer science

«Внутри машины», или как работает ваш компьютер, у нас это называется еще «архитектура ЭВМ». Как устроен процессор, память и вся организация железа. Если у вас нулевой бэкграунд, вам нравятся картинки и тоненькие книжки (~300 страниц), то это то, с чего вам точно стоит начать.

«Введение в компьютерные системы». Тут автор начинает буквально с того, почему процессор делается из кремния, потому что они сами делали процессоры из кремния. И проходится по всему абстракционному стеку, начиная от железа, через периферию, BIOS, операционную систему, ассемблер, язык программирования C, пишут на нем потом программы и покажут, как это дело все между собой связано, взаимодействует в очень интерактивной манере.

«Код» Петцольда. Эта книга, как и первая, тоже для полных новичков, без бэкграунда в сфере. Там рассказывается про то, что такое железо, операционная система, компиляторы, языки программирования, как это дело все между собой взаимодействует. Если вам когда-нибудь было интересно, почему компьютер именно такой, а программы пишутся именно так, то Петцольд в очень простой манере за 400 страниц вам об этом простенько расскажет.

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

Первое — это «Теоретический минимум по Computer Science». Уровень подачи тут не дотягивает до предыдущих трёх, он немножко мудрёнее и сложнее, но тут реально покрывается весь тот компьютер-сайенс необходимый, который вам нужен, и в книге всего 150-200 страниц.

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

«Computer Science: an Overview». Эта книга реально местами довольно часто очень сложная. То есть, если вы не знаете, что такое транзистор, а там об этом узнаете, то вы вряд ли поймете, что такое транзистор.

Но, (а) эта книга реально походится по всему курсу Computer Science, где говорят даже про базы данных и графику, и, (б) там копают чуть глубже, чем в этой, этой или этой. Поэтому, если у вас есть хоть немного опыта программирования, то смело берите эту книгу и изучите Computer Science.

Алгоритмы и структуры данных

Как вы все знаете, это Корман и Седжик.

Но Корман — это очень много математики прямо с первых страниц, а Седжик — это Java, которая, ну, не особо всем нравится.

Но нам везет, и со временем появляются реально годные альтернативы. И одна из них — это Grokking Algorithms. Я о ней узнал года три назад, и года два назад полностью заменил ею Кормана в менторинге. Книгу написал очередной гений, который программирует с двух лет и продает свои первые игры чуть ли не в 10 лет. Но она реально написана простым языком, и хочу сделать небольшую ремарку, если будете читать перевод. В переводах есть ошибки, поэтому просто будьте осторожны и всегда рекомендую только оригинал.

Операционные системы

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

Тут, наверное, есть какой-то баланс, она не слишком глубокая и не слишком поверхностная.

Также мне нравится вот эта книжка, она супер просроченная, я давным-давно ее купил, но если вы хотите знать, как работает Unix, и вам нужен туториал, как написать свой Unix, то это как раз-таки то, и не важно, что ей 200 с лишним лет.

Компиляторы и дизайн языков

Книгу с драконом сразу отсюда убираем, потому что она, ну, прям слишком сложная.

Берем сюда Николаса Вирза, 150 страниц, и добавляем сюда Нистерна с его Crafting Interpreters. Кстати, Нистерн — это тот самый чел, который делал паттерны для геймдева, которые являются чуть ли не аналогом Банды Четырех.

Software development

Clean Code, Code Complete и так далее — ребят, это классные книги, не поймите меня неправильно, они написаны лучшими из нас, но читать их нужно только тогда, когда вы имеете уже от двух до трех лет опыта в программировании. Они учат вас, как делать правильно, и вы, скорее всего, не поймете, как делать правильно, если вы сначала не поделаете неправильно. Тут нереально учиться на чужих ошибках. Рекомендую читать только тогда, когда у вас будет пару пэт-проектов и два-три года опыта в программировании в целом.

Касаемо ООП, все советуют «Банду Четырёх», которая прилично так всем уже надоела.

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

Моя библиотека, GameDev, прочее

Джейсон Грегори — это автор, который написал Uncharted и, соответственно, эту книгу. У него супер-обширные познания в игровых движках как минимум и как максимум в производстве игр. В моменте этот человек решает написать вот эту вот книгу, которая уже третье издание. Отличная подача материала, углубление в самый раз, максимально широченный охват тем. И вот, например, то, что делает тот же самый Ян Черников — это процентов 20-30 вот от этой вот как раз книги. Чаще всего я читаю именно её.

Опять же, Андерсон «Операционки». Тут лучшее объяснение виртуальной памяти, на мой взгляд. Книга по введению в CS и программирование. Просто всем советую. Конечно же, Корман со своей бандой. Они тут явно борщат с математикой, но, может быть, это просто я тупой [здесь не даются ссылки на книги т.к. автор повторяет их из первого раздела, — прим.редактора].

Не особо классная книга по C++, но как референс или подставка для монитора вполне сходит.

Ещё одна классная книга — это Game Coding Complete. Сложные темы рассказывают достаточно простым языком. И именно отсюда я узнал, что такое анимация и как они работают.

Конечно же «Си» Кернигана и Ричи, но я не советую, если у вас с психикой не все в порядке.

Ассембль от Apress, чтобы хоть какое-то понимание было, что это такое, как на него смотреть вообще<...>

Языки программирования

Python

Тут идёт, конечно же, Лутц с его громким именем. Книжка прям для суперновичков, и Лутц, самое главное, не страдает болезнью. Вот это вы пока не понимаете, но через 10 страниц я вам это объясню. Нет, он как в бакалее: всё сразу по полочкам вам раскладывает, и вы перелистываете страницу за страницей, с приятным чувством, что вы все понимаете, вы весь такой вообще умный и сообразительный.

Еще одна книга на уровне этой — «Краш-курс Питона», которая была написана тоже автором, у которого куча классных книг по питону. Он программирует с 5 лет и пишет полжизни книги. Отличие от Лутца в том, что эта книга подходит как и начинающим, так и типам с опытом, поэтому читать ее реально не скучно.

Еще одна классная книга и классный автор — это Дэвид Бизли с его «Python Cookbook». Вообще, Дэвид Бизли — это бывший С-шник, который полжизни пишет на C и в моменте решает преподавать Python. И расскажет про всякие супер интересные и занимательные штуки по типу, почему на Python нельзя программировать многопоточные приложения, почему на нем нельзя программировать мобильные приложения. И у него еще есть всякие видео на YouTube, где он показывает всякие хаки с Python. Поэтому Python Cookbook, если уже знаете основу, то там вас научат расширять даже питоновский интерпретатор.

C

Тут сразу запомните одно. Никогда не читайте книгу Learn C the Hard Way, потому что там автор сразу видно, что не знает, о чем говорит, и упрощает то, что упрощать не надо. У этой книги прям очень много хейта в интернете, как и у книг Шилта, который классно знает Java, но не знает C++ и C, или как минимум не умеет их преподавать.

Волк в овечьей шкуре или Брайан Керниган и Денис Ричи и C, второе издание. Книгу рекомендуют до сих пор изучать по C, но на самом деле там есть куча проблем. Во-первых, это то, что эта книга подразумевает то, что вы уже знаете компьютер-сайенс, как работает вообще все, начиная от железа и вплоть до операционных систем. Во-вторых, то, что она по факту страниц 250, хотел сказать, она по факту 2500, и там нет такого понятия, как best practices, то есть книги 100 лет, и там просто не знали, что такое хорошо, а что такое плохо. Поэтому не рекомендую, если вы не понимаете компьютер-сайенс.

Beginning C. Книга от Apress, которая, как вы видели, у меня уже есть x86 Assembly. Классная книга, классное издательство. Фишка этой книги то, что там рассказывают про C99, про C11, про многопоточность в C.

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

И напоследок, хочу скачать что мне запомнилась, вот эта книга, которая называется Expert C. Она была написана челами, которые классно знают и разбираются в интерпретаторах и работают в САН.

C++

Конкретно от меня, у меня Primer Plus, которая не лучшая из этих книг, но мне хватило ее как референса [автор упоминал её ранее, — прим.редактора].

Мне также очень нравятся книги Скотта Майер Effective C++, которые нравятся вообще всем.

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

Само собой, многопоточность и C++ Concurrency in Action, потому что также нет никакого выбора. Ну и само собой, Александр Эску, которого почитывать нужно как минимум для того, чтобы видеть, как делать не надо, а это всегда в C++ интересно посмотреть.

Java

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

А вот книга Шилда Java Complete Reference, последний, который я читал, шестой и седьмой, мне всегда нравились, потому что простая подача, и они очень похожи на GLS. Наверное, даже проще. Да и вообще, у Шилда читать, мне кажется, можно всё, что угодно, потому что он как бы папа джавы.

Конечно же, как только вы знаете джаву-основу, это Джошуа Блок с ее Effective Java, это аналог Скотта Майера с Effective C++. На моей первой работе на Java, когда я пришел и сказал своему тимлиду, что я читаю Effective Java, он мне говорит, блин, это классная книга, я там дженерики сейчас изучаю. А я стоял в этот момент и думал, что, блин, я ее тоже уже читаю. Было очень приятное чувство, но меня тогда, типа, я так и остался работать джуном, а он так и остался работать тимлидом. Ничего не поменялось. В этой книге реально много практик использования джава в реальном продакшене, поэтому, если знаете основу, смело ее рекомендую.

Java Concurrency in Practice. То есть Java — это исключение, это многопоточность, это OOП. Такие книги, как Java Concurrency in Practice, показывают вам, как использовать ту же самую многопоточность, ее неотъемлемую часть. А такие книги, как Хедферст или какой-нибудь Шилдт, показывают вам, что такое Java Core. Также на уровне с Шилдтом есть тип, которого зовут Кей Хорсман. У него много всяких книг по типу «Как работать с синхронизацией» или «Ближележащие топики». То есть какой-то Advanced Java. Поэтому советую присмотреться тоже.

C#

Пусть Рихтера читают, пусть больше ничего не читают.

Javascript

Симпсон «Вы не знаете JavaScript». Неоднократно слышал про эти книги от классных JS-ников, потому что там много всяких how-to, то есть как работает это, как работает это, почему не работает это.

Советовать Фленнегана или Дугласа Кроуфорда, который хотел назвать JavaScript C++++ я не буду, потому что, если бы вы хотели читать книги, вы бы, наверное, изучали C++. Все-таки JavaScript — это попробовать, потыкать и поучиться на практике.

Assembly

Я покупал себе вот эту книгу и ни разу в ней не разочаровался. Возможно, потому что я прочитал ее только процентов на 30, но какая разница. Наверное, будет хороший вопрос, если вы скажете, зачем мне вообще ассембли в 2022 году. Да, он вам не нужен, вы на нем писать ничего точно не будете, но если вы пишете на плюсах, то чтение ассембли во время дебаггинга, что занимает большую часть вообще времени в программировании, как минимум на C++, как минимум у меня, понимать ассембли хотя бы нужно, поэтому такая вот книга в этом отлично помогает.

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

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

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

Что общего между MacOS и Linux

В первую очередь, обе системы в своей современной итерации разработаны на основе Unix. Также и Linux, и macOS совместимы с POSIX.

POSIX – это стандарт, который определяет совместимость операционных систем, основанных на UNIX.

POSIX (Portable Operating System Interface) был разработан с целью обеспечить переносимость программного обеспечения между различными UNIX-подобными системами.

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

Поддержка POSIX приводит к легкой переносимости серверного программного обеспечения и программ на языках программирования вроде Ruby, Python, gcc, clang, Erlang и многих других, с одной ОС на другую.

Файловая система в ОС выполнена практически идентично, за исключением того, что macOS не чувствителен к регистру.

Также почти все программное обеспечение GNU, то есть практически каждая программа, работающая на компьютере с Linux, доступна для macOS.

GNU – это проект свободного программного обеспечения (Free Software Foundation’s GNU Project), который был запущен Ричардом Столлманом в 1983 году. GNU является сокращением от “GNU’s Not Unix” и представляет собой усовершенствованную и свободную реализацию операционной системы Unix.

Ключевой элемент GNU – это GNU General Public License (GNU GPL), который предоставляет пользователю свободу использовать, изменять и распространять программное обеспечение под лицензией.

Лицензия GNU GPL гарантирует, что программное обеспечение, распространяемое под ее знаком, остается свободным и доступным для всех.

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

В общем, и Linux, и macOS поддерживают эти стандарты, поэтому и складывается ощущение, что операционные системы похожи друг на друга.

В чем разница между macOS и Linux

MacOS почти никак не связана с Linux. На самом деле, родословная macOS старше, чем родословная Linux.

То, что мы сегодня называем macOS, основано на NeXTstep, операционной системе, разработанной NeXT Computing в 1980-х годах.

NeXT — это компания, которую Стив Джобс основал после того, как покинул Apple в 1985 году после конфликта с советом директоров. Да, есть и такая строчка в биографии Джобса.

Стив Джобс основал новую компанию и нанял Ави Теваняна в качестве руководителя отдела разработки программного обеспечения.

Теванян был одним из программистов, разработавших ядро ​​BSD Mach в Университете Карнеги-Меллона, и Джобс попросил его создать на его основе новую многозадачную ОС.

В качестве основы для NeXTstep использовалась Berkeley Unix BSD 4. Berkeley Unix была разработана Калифорнийским университетом в Беркли после Unix System 3.

В Unix System 3 вносили различные улучшения, после чего ОС назвали BSD 4. Более поздняя версия BSD под названием Mach была разработана как раз в Карнеги-Меллоне.

Теванян придумал новую ОС, которая превосходила аналоги на тот момент времени. К примеру, Тим Бернерс-Ли изобрел Всемирную паутину в 1990 году именно на компьютере NeXTstation с NeXTstep в качестве ОС.

В это же время Apple без Стива Джобса пыталась создать собственную ОС, но все было тщетно. Они пришли к решению выкупить NeXT, и Джобс вернулся в компанию.

Теванян, который стал новым руководителем отдела разработки программного обеспечения Apple, затем переработал NeXTstep в Mac OS X.

Это до сих пор влияет на работу macOS: в ней инструменты командной строки взяты из *BSD, а в Linux они заимствованы из GNU.

Даже сегодня, если вы посмотрите на API macOS, вы заметите, что многие вызовы API, имена классов и функции AppKit начинаются с «NS», например, NSOpenPanel, NSSavePanel, NSWindow, NSResponder и так далее.

«NS» здесь означает «NeXTSTEP». Даже объект, который обрабатывает основной цикл событий в приложении AppKit, называется NSApplication.

Linux был разработан позже. Ядро ​​Linux было написано только в 1991 году, а первые дистрибутивы GNU/Linux появились в 1992 году. NeXTstep была выпущена 18 сентября 1989 года и была уже отполированной ОС, которую можно было использовать для серьезных проектов. Этих высот Linux смогла добиться только несколько лет спустя.

Таким образом, macOS — это не просто дорогая и симпатичная Linux. Это симпатичная NeXTSTEP, которая была симпатичной BSD Unix.

MacOS — это операционная система BSD UNIX на основе микроядра с собственной собственной подсистемой отображения, архитектурой драйверов и оконным менеджером.

Linux представляет собой монолитное ядро ​​без родословной UNIX, но благодаря библиотекам и утилитам GNU обеспечивает UNIX-подобную среду POSIX.

Почему различия между Linux и macOS важны

Теперь, после того как мы выяснили, что у Linux и macOS разные ядра, поговорим о том, почему это вообще важно для пользователя. Дело в том, что Linux с его монолитным ядром выиграл «войну ядер», которая до сих пор не закончена.

Монолитное ядро Linux – это тип архитектуры ядра операционной системы, в котором все основные функции и драйверы находятся внутри одной исполняемой программы – ядра. В монолитном ядре все части ядра работают в одном адресном пространстве и имеют прямой доступ к аппаратным ресурсам компьютера.

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

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

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

В macOS (ранее известной как Mac OS X и OS X) используется микроядро XNU (X is Not Unix). XNU является гибридным ядром, в котором сочетаются микроядро и некоторые элементы архитектуры монолитного ядра. Хотя ядро XNU является гибридным, его основной архитектурой является микроядро.

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

Но и у macOS есть преимущество. Микроядро стабильнее. Если один модуль даст сбой, все остальные модули будут работать и дальше.

В этом смысле, вам решать, что важнее: надежность или скорость.

И чтобы освежить знакомые всем команды, не меняя сильно логику их работы, было создано множество альтернатив. И 25 из них были собраны на GitHub-репозитории Modern Unix.

bat

Например, команду cat можно заменить с помощью bat. Она, как и оригинал, позволяет выводить на экран содержимое файлов. Только в отличие от устаревшей Unix-утилиты поддерживает подсветку и прочие современные возможности.

lsd

Есть и продвинутая версия ls — lsd. Эта утилита написана на Rust, что делает её достаточно быстрой. При этом имеются версии практически на все платформы: от Archlinux и Fedora до macOS и Windows.

zoxide

В подборку попала и «умная» замена базовой команде cd — zoxide. В отличие от предмета своего вдохновения, новинка умеет понимать, какая директория наиболее подходит под ваши запросы.

С полным списком альтернатив Unix-команд можно ознакомиться на странице Modern Unix. Там же есть ссылки на все проекты.

«Сломал» загрузку систем апдейт BIOS под номером 0058. Из-за проблем с ACPI, при работе с Linux, FreeBSD, NetBSD возникли ошибки, в то время как Windows 10 работает в штатном режиме, пишет OpenNET.

На момент написания материала, более десяти владельцев Intel NUC подтвердили наличие проблемы. Компания Intel уже убрала «испорченное» обновление BIOS из «Центра Загрузки ПО», а пострадавшим предложила заменить компьютеры либо дождаться следующего патча.

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

Источник: OpenNET

Минутка истории

Ошибка Y2K заключалась в следующем. В 1950-х и 60-х годах, когда создавался софт для первых компьютеров, разработчики отображали год в дате двумя последними цифрами. Для экономии ресурсов. Поэтому они переживали, что 1 января 2000 года компьютеры, отображающие новую дату «00», ошибочно решат, что это 1900 год.

Это звучало правдоподобно, и многие люди сделали бизнес на консультациях по этому вопросу. Вырос спрос на COBOL-разработчиков — им приходилось исправлять старые приложения. По мере приближения Миллениума люди готовились к глупым коммунальным платежам, гаснущим фонарям и падающим самолётам

В конце концов, появились Y2K-совместимые системы, и 2000 год начался почти без шума. Но «проблема 2038 года» немного сложнее.

Что произойдёт в 2038 году

Время Unix — это количество секунд, начиная с полуночи 1 января 1970 года. Отсчёт начался с 0, и любое значение времени или даты выражается числом секунд, следующих за 0. Так, значение 919642718 равно 919 642 718 секундам после 00:00:00 часов 1 января 1970 года. То есть воскресенью 16:18:38 21 февраля 1999 года.

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

Старые 32-разрядные процессоры способны считать только до 2 147 483 647. Таким образом, 19 января 2038 года в 03:14:07 по Всемирному времени (UTC) они достигнут максимальной мощности.

Проблема 2038 года приведёт к тому, что часы на некоторых устройствах перестанут работать. По одной из теорий, время обернётся назад к «началу» и будет храниться в виде отрицательных чисел. И из-за того, как написан код, компьютеры будут интерпретировать это время как происходящее 13 декабря 1901 года, а не 19 января.

Всё не так плохо

Большинство компьютеров и смартфонов, сделанных в последнее время, 64-разрядные и могут содержать числа размером 9 223 372 036 854 775 807. То есть будут отсчитывать время до 292 277 026 596 года. Так что их основная часть (за исключением действительно старых) не пострадает.

Что касается банкоматов, медицинской и военной техники и прочего, то к 2038 году, вполне вероятно, большинство (если не все) 32-битных устройств не будут использовать. Им на замену придут более современные системы, которые не нужно исправлять. Главной головной болью может стать модернизация оборудования. Но инженеров есть ещё 18 лет, чтобы с ней справиться.

Введение

Шаблон задания для Cron выглядит примерно так:

Вот иллюстрация этого же шаблона, которую можно сохранить себе:

Звёздочками обозначены конкретные блоки времени.

Для отображения содержимого crontab-файла текущего пользователя используйте команду:

Для редактирования заданий пользователя есть команда:

Если эта команда выполняется в первый раз, вам предложат выбрать редактор для Cron:

Выбирайте на своё усмотрение. Вот так изначально выглядит crontab-файл:

В этом файле как раз нужно перечислять одну за другой все команды.

Чтобы изменить crontab-файл другого пользователя (например, ostechnix):

Ниже приведены несколько примеров cron-заданий:

1. Чтобы выполнять команду каждую минуту, задание должно быть такое:* * * * * <исполняемая-команда>
2. Похожее задание, только команда будет вызываться каждые пять минут:*/5 * * * * <исполняемая-команда>
3. Вызывать команду 4 раза в час (каждые 15 минут):*/15 * * * * <исполняемая-команда>
4. Чтобы выполнить команду каждый час в 30 минут, пишем:30 * * * * <исполняемая-команда>Т. е. команда будет выполняться не каждые 30 минут, а тогда, когда значение минут будет равно 30 (например, 10:30, 11:30, 12:30 и т. д.).
5. Значения времени можно комбинировать, перечислив их через запятую. Следующий код будет выполнять команду три раза в час: в 0, 5 и 10 минут.0,5,10 * * * * <исполняемая-команда>
6. Выполнять команду каждый час будет следующее задание:0 * * * * <исполняемая-команда>
7. Выполнение команды каждые два часа:0 */2 * * * <исполняемая-команда>
8. Чтобы выполнять команду каждый день (в 00:00):0 0 * * * <исполняемая-команда>
9. Выполнение команды каждый день в 03:00:0 3 * * * <исполняемая-команда>
10. Выполнение команды каждое воскресенье (sunday):0 0 * * SUN <исполняемая-команда>
11. Другой вариант задания, которое будет выполнять команду каждое воскресенье (естественно, тоже в 00:00):0 0 * * 0 <исполняемая-команда>
12. Выполнение команды каждый день с понедельника по пятницу:0 0 * * 1-5 <исполняемая-команда>
13. Следующее задание будет выполнять команду каждый месяц, 1-го числа в 00:00:0 0 1 * * <исполняемая-команда>
14. Выполнять команду в 16:15 каждого первого числа месяца будет это задание:15 16 1 * * <исполняемая-команда>
15. Выполнение команды каждые три месяца:0 0 1 */3 * <исполняемая-команда>
16. Выполнение команды в строго определённое время и месяц:5 0 * 4 * <исполняемая-команда>
17. Задание будет вызывать команду в начале каждого полугодия (в 00:00 1-го дня):0 0 1 */6 * <исполняемая-команда>
18. Выполнение команды каждый год 1-го января в 00:00:0 0 1 1 * <исполняемая-команда>

Ещё существуют готовые задания:

• @reboot — одиночное выполнение команды при загрузке;
• @yearly — раз в год;
• @annually — тоже раз в год;
• @monthly — раз в месяц;
• @weekly — один раз в неделю;
• @daily —  раз в день;
• @midnight — тоже раз в день;
• @hourly — раз в час.

Чтобы выполнять команду каждый раз после перезапуска сервера, используйте это задание:

Команда для очистки всех заданий текущего пользователя:

Чтобы узнать о подробностях, есть команда:

Вышеперечисленного уже должно хватить для базовой работы с Cron и составления заданий.

Синтаксис crontab-генераторов

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

Crontab.guru

crontab.guru — отличный сайт, чтобы изучить различные примеры cron-заданий. Просто введите данные и сайт самостоятельно сгенерирует конечное задание.

На сайте есть разделы, посвящённые примерам и советам.

Crontag Generator

crontab-generator.org — ещё один сайт, который помогает быстро сгенерировать crotab-выражения. Принцип такой же: нужно ввести все необходимые данные в формы и нажать кнопку «Generate Crontab Line» внизу страницы.

Вот такое конечное выражение вы увидете на сайте:

Помимо этого, есть веб-инструмент «Crontab UI», который обеспечивает не только простоту создания crontab-заданий, но и безопасность. Вот статья, посвящённая этому инструменту.

Изменения в обновлении

Помимо исправления багов, в новой версии разработчики:

• Убрали привязку действий по умолчанию к клавишам F13, F14 и F15.
• Добавили учёт функции --fill при изменении размера файлов.
• Реализовали возможность открыть другие файлы в режиме просмотра (использование --restricted вместе с --view запрещает её).
• Добавили обработку файлов nanorc в ограниченном режиме. Пользователь может отключить чтение файлов с помощью функции --ignorercfiles.
• Переименовали функции prevhistory и nexthistory в older и newer(для этого необходимо изменить файлы nanorc).
• Функция --zap привязана к комбинации клавиш Alt и Delete для строк, а также к Backspace и Delete для выделенных областей. С помощью функции разработчик удаляет строки или выделенные области без изменения буфера удалённой информации.
• Изменили комбинацию клавиш по умолчанию для вызова функции linter. Она вызывается одновременным нажатием Meta и B, а сочетание Ctrl и T изменяет цвет строки состояния и текст заголовка. При этом его можно использовать в режиме анализа приложения.

GNU nano — это свободный текстовый редактор для использования в консоли UNIX и Unix-подобных систем. Он является копией редактора Pico, встроенного в почтовый клиент Pine. Разработчики nano объявили о выходе третьей версии в начале сентября 2018 года. В nano 3.0 они ускорили обработку ASCII и чтение файлов, добавили новые сочетания клавиш и исправили ошибки, связанные с отображением текста.

Что нового в nano 3.0

• Скорость чтения файлов возросла на 70 %, а обработки ASCII-текста — удвоилась.
• Изменен способ удаления слова в конце строки.
• Сочетание клавиш Ctrl+Delete теперь стирает следующее за кареткой слово, Ctrl+Shift+Delete — предыдущее, а Alt+Q выполняет поиск в обратном направлении.
• Проверку орфографии внешними инструментами можно запретить.
• Исправлена ошибка нумерации строк при открытии нескольких файлов.
• Удалена команда formatter и функция searchagain, поэтому Alt+W теперь по умолчанию выполняет findnext.
• Кнопка No-Convert перемещена в меню Insert.
• Кнопки Backup и New-Buffer удалены из главного меню, но остались в Write-Out и Insert соответственно.
• Программа игнорирует нажатие на Esc, если за ним следует командное сочетание клавиш.
• Сообщения об ошибке rcfile теперь не скрываются в Linux-консоли.

GNU nano — это свободный текстовый редактор для использования в консоли UNIX и Unix-подобных систем. Он является копией редактора Pico, встроенного в почтовый клиент Pine. В дальнейшем приложение получило подсветку синтаксиса, поддержку регулярных выражений при поиске и замене, а также многоуровневый буфер обмена и другие возможности, отсутствовавшие в Pico.

Компоненты FreeBSD 11.2

Компоненты Clang, libc++, compiler-rt, LLDB, LLD и LLVM получили обновления и улучшения, их актуальная версия теперь — 6.0.0. Новые возможности Clang:

• включение по умолчанию стандарта С++14, поддержка возможностей С++2а в будущем;
• интеграция патчей retpoline для блокирования второго варианта уязвимости Spectre;
• работающий по умолчанию фреймворк GlobalISel для архитектуры AArch64 при сборке с уровнем оптимизации -O0;
• новые предупреждения компилятора.

Драйверы и сторонние проекты

Новые версии получили сторонние проекты, поставляемые вместе с ОС: libarchive 3.3.2, libxo 0.8.4, Subversion 1.9.7, OpenSSH 7.5p1, tcpdump 4.9.2, NTP 4.2.8p11, bmake 20180222, OpenSSL 1.0.2o, LLVM (clang, lld, lldb, compiler-rt) 6.0.0.

Обновлены драйверы устройств cxgbe, ixl и ng_pppoe. Кроме того, в FreeBSD добавлены новые драйверы mlx5io для сетевых адаптеров Connect-X 4 и Connect-X 5, ocs_fc для хост-адаптеров Fibre Channel от компании Emulex и smartpqi для SCSI-контроллеров Microsemi.

Утилиты

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

• efibootmgr для настройки менеджера загрузки EFI;
• dwatch для наблюдения за процессами с использованием механизма трассировки DTrace;
• etdump для просмотра информации из загрузочного каталога El Torito.

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

Среди остальных изменений можно отметить поддержку Wake On LAN по умолчанию для систем на базе процессоров Intel Ice Lake и Cannon Lake, многопротокольных адаптеров TAIO USB (TUMPA), а также уменьшенный размер инсталлятора, который теперь умещается в 700 МБ.

Популярные ОС нередко становятся объектами хакерских атак и поиска уязвимостей. В мае 2018 года исследователями кибербезопасности была найдена брешь, затрагивающая Windows, macOS, Linux, FreeBSD, Red Hat, Ubuntu и некоторые реализации гипервизора Xen.

• Структура и архитектура некоторых современных дистрибутивов Linux.
• Вопросы установки и начальной настройки Linux-based операционных систем.
• Вопросы повседневного использования Linux-based операционных систем.
• Подход к использованию UNIX-system («UNIX way»).
• Основные понятия и концепции современных Linux-based дистрибутивов.

Курс ориентирован на слушателей, имеющих малый практический опыт в использовании UNIX-like систем и современных Linux-based дистрибутивов операционных систем. Кстати, когда освоитесь с терминалом, обратите внимание на нашу подборку интересных команд — они сделают вашу повседневную работу проще и приятнее.

Конспекты, видео- и аудиозаписи всех лекций можно скачать на на сайте информационной поддержки курса.

Если вы когда-нибудь работали c Unix-системами, то наверняка слышали термин “демон”. В этой статье я хочу объяснить, что это за демоны и как они работают, тем более что их название заставляет думать, что это что-то плохое.

Вообще демон — это фоновый процесс, который не привязан к терминалу, в котором был запущен. Но как они создаются, как они связаны с другими процессами, как они работают? Об этом мы и поговорим, но сперва давайте узнаем, как работает процесс init и как происходит рождение новых процессов.

Как работает процесс Init

Для начала поговорим о процессе init, также известном как PID 1 (поскольку его ID всегда равен 1). Это процесс создаётся сразу при запуске системы, то есть все другие процессы являются его потомками.

Обычно init запускается, когда ядро вызывает конкретный файл, обычно находящийся по адресу /etc/rc или /etc/inittab. Процесс устанавливает путь, проверяет файловую систему, инициализирует серийные порты, задаёт время и т.д. В последнюю очередь он запускает все необходимые фоновые процессы — в виде демонов. Все демоны обычно расположены в папке /etc/init.d/; принято оканчивать имена демонов на букву d (например, httpd, sshd, mysqld и т.п.), поэтому вы можете подумать, что директория названа так по этому же принципу, но на самом деле существует соглашение об именовании папок, содержащих конфигурационные файлы, именем с суффиксом .d. Итак, init запускает демонов, но мы так и не выяснили, как это происходит. Процесс init запускает демонов, создавая свои ответвления для запуска новых процессов.

Как работает разветвление процессов

Единственный способ создать новый процесс в Unix — скопировать существующий. Этот метод, известный как разветвление или форкинг, включает в себя создание копии процесса в виде потомка и системный вызов exec для запуска новой программы. Мы использовали слово “форкинг”, поскольку fork — это реальный метод C в стандартной библиотеке Unix, который создаёт новые процессы именно таким образом. Процесс, вызывающий команду fork, считается родительским по отношению к созданному. Процесс-потомок почти полностью совпадает с родительским: отличаются лишь ID, родительские ID и некоторые другие моменты.

В современных дистрибутивах Unix и Linux процессы можно создавать и другими способами (например, при помощи posix_spawn), но большая часть процессов создаётся именно так.

Теперь, когда вы узнали о традиционном значении термина “fork”, становится понятно, почему такое же понятие используется на GitHub. Но я отвлекся — вернемся к нашим демонам!

Как работают демоны

Прежде чем мы углубимся в работу демонов, давайте выясним, откуда взялось это название. Термин “демон” возник из Project MAC, который в свою очередь получил своё имя от демона Максвелла — вымышленного существа из мысленного эксперимента, которое постянно сортирует молекулы. Само слово демон происходит от греческого daemon, являющегося сверхъестественным существом, которое постоянно работает на заднем плане и не является добрым или злым (в отличие от обычного современного значения). То есть, термин “демон” (в смысле Unix-процесса) на самом деле произошёл от вымышленного сверхъестественного существа.

Демоны — это фоновые процессы, работающие отдельно от терминала и почти всегда созданные процессом init; обычно они занимаются такими вещами, как сетевые запросы, работой аппаратного обеспечения и прочими заданиями типа “жди и смотри”.

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

Когда вы создаёте процесс-потомок и тут же “убиваете” его родителя, потомок становится процессом-сиротой (не стоит путать с процессом-зомби, например, потомком, который был завершен, но всё ещё ждёт, когда родитель прочтёт его exit-статус). По умолчанию, если процесс становится сиротой, то его “приёмным” родителем становится init. Вот и всё, что делает демонов уникальными!

Заключение

В целом демоны — это очень простая для понимания концепция, но чтобы полностью в них разобраться, нам понадобилось узнать, что такое init-процесс и как устроено разветвление процессов.

UNIX-время будет равняться 0x58000000 в 21:43:28 по Гринвичу (заметим, что по UTC это ещё 13 октября, тогда как по московскому временеи будет уже 14-е). Достаём шампанское! Чтобы узнать, когда это произойдёт в вашем часовом поясе, можно воспользоваться простеньким Perl-скриптом:

Наблюдать за UNIX-временем в онлайн режиме вы можете прямо на этой странице:

C «Новым полугодом», коллеги!

Я купил первый наш NeXT (ColorStation) из личного интереса. Джейсон Блочуйак рассказал мне о преимуществах систем, основанных на Unix, и мне было очень интересно, что же крутого снова сделал Стив Джобс. Забавно сейчас вспоминать об этом — я тогда на полном серьёзе обдумывал, какие же преимущества для разработки даёт мультипроцессное окружение, если сравнивать с DOS и старыми окружениями Apple, которые мы тогда использовали. Использование NeXT открыло мне глаза, и мне сразу стало ясно, что преимуществ много и они для нас вполне осязаемы. Поэтому мы перенесли всю разработку на NeXT, за исключением пиксель-арта (который выполнялся в Deluxe Paint на DOS). Одним из уникальных преимуществ NeXT (но далеко не единственным) была возможность использовать Interface Builder. Не хватало только Turbo Debugger 386, он был гораздо лучше аналога для NeXT. В итоге Кевин Клауд даже делал мануалы к нашим играм (начиная с Wolfenstein 3D) в Framemaker на NeXT.Нужно понимать, что альтернативой тогда были DOS и Windows 3.x; то, что теперь система не крашилась постоянно, было прорывом. К моменту выхода Quake 2, Windows NT тоже пришла в состояние “уже-не-крашится-каждую-минуту”, в ней было аппаратное ускорение OpenGL, Visual Studio стала становиться довольно хорошей… В итоге я оценил все наши рабочие станции на Unix и не нашёл причин не перейти обратно на продукты Microsoft.В итоге за время разработки Doom и Quake 1 мы потратили около 100 тысяч долларов на компьютеры NeXT, что, в общем-то, не слишком много. Впоследствии мы потратили гораздо больше на серверные системы Unix SMP.

Говоря о Кармаке, стоит помнить, что речь идёт о человеке, который в 1995-м году пользовался 28-дюймовым монитором.

Этот монстр поддерживал разрешения до 1920 х 1080 (16:9!) и потреблял 180 ватт электроэнергии (17″ ЭЛТ-монитор потребляет примерно 70–80 Вт, современный 22″ ЖК-монитор потребляет порядка 35 Вт). Если говорить совсем честно, то диагональ самого экрана была только 25.9″, но этого всё равно хватало, чтобы вызывать зависть у большинства программистов (и геймеров) в 1995 году.

Чтобы запустить всё это, нужно сначала скачать ISO образ. Затем либо записать его на обычный CD, либо промонтировать к виртуальной машине (VMware или VirtualBox, например). Также доступен исходник, из которого собирался образ.

После включения начала стартует Sanos, который запускает симулятор PDP-11. А уже симулятор, в свою очередь, загружает UNIX V7 из образа.

• При первом запросе ввода пишем b
• При следующем (появится символ @): boot<enter>
• Затем rl(0,0)rl2unix<enter>
• Когда увидите # нажмите <ctrl-d>
• Заходим в систему с логином root, паролем root

Готово, седьмая версия UNIX запущена. Теперь можно использовать обычные команды UNIX вроде cat, ls, man и т.д.

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

Код взят с GitHub Gist.