Процесс загрузки Linux начинается с нажатия кнопки питания, после чего процессор переходит в реальный режим (real mode) и выполняет инструкцию по адресу сброса 0xFFFFFFF0. Это приводит к запуску микропрограммы на материнской плате (BIOS или UEFI), которая выполняет самотестирование (POST) и ищет загрузочное устройство. При обнаружении загрузочного сектора (маркеры 0x55 и 0xAA), BIOS копирует его в память по адресу 0x7C00, после чего управление передается загрузчику GRUB. GRUB считывает свою конфигурацию, загружает ядро Linux в память и передает управление программе настройки, которая создает предсказуемую рабочую среду: выравнивает сегментные регистры, создает стек, очищает область BSS и запрашивает информацию о доступной памяти у микропрограммы. В конце концов, вызывается первая функция C с именем main, что标志着 переход к следующей фазе загрузки.

• Обсуждение показало, что статья о процессе загрузки Linux охватывает только самые базовые концепции, что вызвало критику за упрощение и упущение важных деталей, таких как взаимодействие с UEFI, инициализация видео и роль загрузчика.
• Участники подчеркнули, что статья не соответствует уровню подготовки аудитории Hacker News, и что она не раскрывает важные темы, такие как влияние UEFI на процесс загрузки.
• Также было отмечено, что статья не затрагивает такие важные темы, как влияние UEFI на процесс загрузки и не упоминает о таких важных компонентах, как initrd и драйверы.
• Некоторые комментаторы выразили сожаление по поводу того, что статья не затрагивает такие темы, как влияние systemd на процесс загрузки и не упоминает о таких важных компонентах, как initrd и драйверы.
• Также было отмечено, что статья не упоминает о таких важных компонентах, как initrd и драйверы, и не раскрывает влияние systemd на процесс загрузки.

В статье рассматривается создание микро-Linux дистрибутива с нуля, включая сборку ядра Linux и разработку ПО для упаковки. Пример реализован для архитектуры RISC-V (QEMU riscv64 virt), но подход применим и к x86. Автор предупреждает, что это упрощенное представление Linux-дистрибутива, предназначенное для начинающих, и некоторые детали могут быть неточны на 0.1%.

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

• Обсуждение вращается вокруг создания минимальной Linux-системы: от идеи до практических нюансов (UEFI, cloud-init, PXE, initramfs, cpio, u-root, kexec, Gentoo vs LFS vs Buildroot).
• Участники делятся опытом, что «маленькая» сборка может быть полезна как для обучения, так и для практического применения (например, как образ для облачных инстансов).
• Обсуждаются различные инструменты и подходы: от полностью статически слинкованных бинарников до полноценных дистрибутивов, а также варианты с использованием u-root, kexec, initramfs, cpio, PXE и т.д.
• Участники также обсуждают, что такие мини-дистрибутивы могут быть полезны для обучения, отладки и даже как основа для специализированных образов (например, для RPi или как образ для облачных провайдеров).

Asciinema — платформа для записи и обмена терминальными сессиями, позволяющая пользователям сохранять командную работу в различных форматах. На представленном примере запись "untitled" от пользователя crc набрала 3676 просмотров и доступна для скачивания в оригинальном формате .cast, текстовом варианте .txt или в виде анимированного GIF. Платформа поддерживает воспроизведение в терминале с помощью asciinema play и встраивание на веб-сайты через специальный плеер.

Пользователи могут делиться записями с параметрами запуска (например, указывать время начала воспроизведения через ?t=30), встраивать скриншоты в README проектов и конвертировать терминальные сессии в GIF с помощью утилиты agg. Asciinema также предоставляет CLI-инструменты для локального воспроизведения записей и предлагает варианты встраивания для различных платформ, включая HTML и Markdown.

• Обсуждение охватывает от Open Firmware и Forth до внутреннего конфликта имени ILO/ILO и влияния на OLPC, а также затрагивает вопросы эстетики и практичности в контексте встроенного ПО и влияния на разработчиков.
• Участники обсуждают, что такое "открытая прошивка" и как она влияет на разработчиков и пользователей, а также затрагивает вопросы лицензирования и патентов.
• Обсуждение также затрагивает вопросы влияния на OLPC и другие проекты, а также затрагивает вопросы влияния на пользователей и разработчиков.
• Участники также обсуждают, как влияет выбор инструментов на разработчиков и их продуктивность, а также затрагивает вопросы влияния на пользователей.

Введение в гипервизоры на Rust

1. Введение

• Предварительные требования
• Цели курса
• Мотивация
• Как достигаются цели
• Что вы изучите
• Дизайн фаззера
• Дизайн гипервизора
• Что этот курс НЕ охватывает
• Демо: фаззер на основе гипервизора
• Зачем использовать гипервизор для фаззинга
• Приложения UEFI
• Язык Rust
• Классификация гипервизоров
• Гипервизор vs хост, ВМ vs гость
• Типы гипервизоров

2. Настройка и цикл работы гипервизора

• Включение: активация аппаратной виртуализации
• Настройка: создание структуры контекста гостя
• Переключение: запуск в гостевом режиме
• Возврат: переход обратно в режим хоста
• Обработка: эмуляция событий
• Цели и упражнения главы
• Тестирование с Bochs
• Подготовка к упражнениям
• E#1: Включение VMX/SVM
• E#2: Настройка VMCS/VMCB
• E#3: Конфигурация гостевого состояния
• Причины VM-выходов
• Альтернативный дизайн гипервизора

3. Виртуализация памяти

• Терминология
• Традиционная страничная организация x64
• Вложенная страничная организация
• Связь с гипервизором
• Ошибки страниц во вложенной организации
• Структурные элементы вложенной организации
• Сравнение традиционного и вложенного подходов
• Цели и упражнения главы
• E#4: Включение вложенной организации
• E#5: Построение структур и трансляция адресов
• E#6: Реализация copy-on-write и быстрого восстановления памяти
• Продвинутые темы

4. Интроспекция ВМ для фаззинга

• Проблема 1: Ненужное выполнение кода

• Пользователи высоко оценивают качество и полезность материалов по созданию гипервизора и операционной системы, связывая их с предыдущей работой автора.
• Высказывается критика в адрес формата материалов (Markdown/HTML) и пожелание иметь возможность скачивания в PDF для архивации.
• Отмечается, что материал представляет собой конспект/слайды курса и может быть сложен для понимания без предварительных знаний или посещения занятий.
• Возникает дискуссия о практической ценности таких материалов для самообразования без наличия глубоких базовых знаний.
• Упоминается растущий интерес к теме создания гипервизоров, о чём свидетельствует частое появление подобных руководств.
• Предлагаются технические решения для создания PDF-версии (например, печать в PDF через браузер).
• В комментариях присутствует лёгкое обсуждение терминологии (значение слова "hypervisor") и личный опыт работы в данной области.

KDE Linux — новая неизменяемая ОС от KDE на базе Arch, но без pacman.
Корень — Btrfs, /usr — только для чтения (EROFS), обновления атомарные, откат до 5 версий.
Wayland-only, UEFI-only, X11 и BIOS не поддерживаются.
Собирается через KDE Builder, приложения — Flatpak.
Цель: показать «идеальный» KDE-стек без ограничений сторонних дистрибутивов.
Альфа представлена на Akademy 2025; KDE neon пока жив, но будущее не решено.

• KDE Linux — неизменяемая, Wayland-only система на базе пакетов Arch, но без pacman; всё ПО ставится Flatpak-ом или собирается KDE Builder.
• Пользователи делятся: кому-то нравится стабильное «железное» ядро и UX-first подход, других пугает отсутствие X11, невозможность докинуть модули в базу и зависимость от «багового» Flatpak.
• Критики считают проект «еще одним дистрибутивом ради дистрибутива», отвлекающим силы от самой KDE, и предлагают использовать готовые immutable-решения (Fedora Kinoite, Aeon, Arkane).

• AMD на IFA-2025: «x86 уже не менее экономичен, чем Arm»
• Компания уверена, что ноутбуки на Ryzen и Core живут столько же, сколько Arm-решения, при этом сохраняют совместимость с огромной экосистемой x86
• AMD считает, что энергоэффективность определяется не архитектурой, а всей платформой: ядро, GPU, память, ПО
• Проект K12 на Arm был закрыт: выгоды от перехода на другой ISA оказались несоразмерны потерям совместимости

• Эксперты сходятся: ISA (x86, ARM, RISC-V) почти не влияет на энергоэффективность; решают микроархитектура, техпроцесс, uncore, PMIC и ОС.
• Apple M — лидер не из-за ARM, а благодаря интеграции памяти, тонкому управлению питанием и приоритету эффективности.
• Современные x86 (Lunar Lake, Strix Halo) подтянулись по idle, но при нагрузке всё ещё уступают M4 в производительности/Вт.
• ARM-системы всё ещё страдают от хаоса загрузки (no UEFI, vendor-kernel), тогда как x86/PC стандартизированы с BIOS/UEFI.
• Для мелких ядер (MCU) простой ISA важен; для высокопроизводительных ядер декодер «съедает» <1 % площади и энергии.
• Всё сводится к реализации: тот же GCC на x86 генерирует RISC-подобные инструкции, а различия даёт предсказатель, кэши, техпроцесс.

• Модуль: src

• Изменил: mglocker@cvs.openbsd.org, 01.09.2025

• Файлы:
  distrib/arm64/iso/Makefile
distrib/arm64/ramdisk/Makefile install.md list

• Суть: добавлена поддержка Raspberry Pi 5 Model B в RAMDISK.

• Проблемы:

  • Не грузится с PCIe-накопителей (нет U-Boot).
  • Wi-Fi на платах «d0» не работает.
  • Кулер не крутится — отсутствуют драйверы PWM/clock.

Утверждено: kettenis@, deraadt@

• На Raspberry Pi 5 и CM5 в OpenBSD пока не работает Wi-Fi (на «d0»-ревизии плат) и не крутится активный кулер — не хватает драйверов PWM/clock.
• Поддержка всё ещё неполная: аппаратный старт происходит через GPU, документации мало, поэтому U-Boot и драйверы догоняют медленно.
• На Pi 4 OpenBSD уже запускается стабильно, но нужны свежие прошивка и UEFI, а также сторонний firmware для использования >3 ГБ ОЗУ.
• Плюсы OpenBSD на ARM: чистая и последовательная система, «всё в базе» (httpd, spamd, WireGuard через ifconfig), можно носить «сервер в кармане».
• Минусы: нет power-saving на ARM64, после неожиданного отключения могут поломаться системные файлы, а список поддерживаемого «железа» ограничен.

EDK2 UEFI на ROCK 5 ITX+
Плата ROCK 5 ITX+ (RK3588, 32 ГБ eMMC, два M.2, PoE) удобна, но слот microSD сбоку мешает быстро менять ОС. Вместо корпуса и удлинителя решено прошить SPI-память UEFI-фирмой EDK2-RK3588 и грузить образы с USB.

EDK2-RK3588
Проект поставляет PC-образный UEFI для плат на RK3588, обещая загрузку Windows, Linux, BSD и ESXi. На ROCK 5 ITX+ фирма не стартует ни с microSD, ни с eMMC — требуется запись во встроенный SPI-флеш.

Процесс

1. Загружаем Armbian 25.2.2 Noble Gnome (kernel 6.1).
2. В браузере скачиваем последний релиз rock-5-itx с GitHub EDK2-RK3588.
3. Прошиваем SPI командой rockchip_spi_update (предварительно сделав дамп оригинала).
4. Перезагружаемся, выбираем в UEFI нужный USB-накопитель и ставим любой ARM-дистрибутив.

Результат
Теперь ОС можно менять без открытия корпуса и вынимания карты — достаточно вставить флешку и выбрать её в меню UEFI.

• U-Boot уже умеет достаточно UEFI, чтобы запускать Linux/BSD без родного прошивочного слоя.
• Участники хотят отказаться от «SD-карт-флешалок» и получить единый стандарт загрузки, но ARM-вендоры медленно внедряют SystemReady.
• Основные проблемы ARM: отсутствие единой среды загрузки и надёжного механизма авто-обнаружения железа; «ванильные» образы дистрибутивов почти никогда не стартуют без доработки.
• Кто-то предлагает усилить IEEE 1275/Open Firmware вместо UEFI, другие считают UEFI «безумием», но всё же лучше произвола каждого SoC.
• В RISC-V для серверов UEFI уже обязателен по спецификации, чего пока не скажешь о большинстве ARM-плат.

• Почему Pi?
  На слабом железе быстрее всплывают ошибки конфигурации, поэтому эксперимент с TrueNAS на Pi 5 — отличный способ учиться.

• Проблема: нет UEFI
  Pi официально не поддерживает UEFI. Используем форк rpi5-uefi.

• Подготовка Pi 5

  1. Обновите EEPROM до ≥ 2025-06-09 (sudo rpi-eeprom-update -a, при необходимости переключитесь на beta-канал).
  2. Скачайте последний релиз rpi5-uefi, распакуйте содержимое .zip в FAT32-раздел microSD.
  3. Вставьте карту, подключите HDMI, включите Pi. Должен появиться EDK2 Boot Manager.

• Установка TrueNAS

  1. Скачайте ARM-образ TrueNAS (например, 25.04.2) с truenas-releases.jmay.us.
  2. Запишите ISO на USB-накопитель (Etcher).
  3. Загрузитесь с USB через UEFI Boot Manager.
  4. Установите TrueNAS на любой диск, кроме microSD и установочной флешки (второй USB или NVMe).

• Кто-то давно отказался от TrueNAS/FreeNAS в пользу самостоятельной настройки Samba+NFS+ZFS на мини-ПК.
• Многие считают Raspberry Pi слабым и ненадёжным для NAS: проблемы с SATA/USB, отсутствие ECC, низкая пропускная способность.
• Другие успешно годами держат Pi-4 с Ubuntu+Samba+Jenkins, но используют внешние USB-хабы и не нагружают систему.
• TrueNAS критикуют за громоздкий UI, «лагающие» бэкапы Time Machine и лишний оверхед на слабом железе.
• Часть участников предпочитают готовые решения (QNAP, Synology) или Proxmox+ZFS на Intel N100: быстрее, стабильнее, проще.