Автор представляет ежегодную сборку компактного 8-отсечного DIY NAS объёмом менее 20 литров: TrueNAS 25.10.1, Intel Core 3 N355, 32 ГБ DDR5 RAM, 10GbE-сеть. Это 14-я итерация с 2012 года, ориентированная на его критерии: малый форм-фактор, минимум 6 отсеков (учитывая рост ёмкости HDD), низкопотребляющий интегрированный CPU для круглосуточной работы и потенциал homelab для VM/контейнеров.

Рынок компонентов ухудшается: растут цены на HDD, SSD (график 1 ТБ NVMe), RAM; ожидается дефицит Intel CPU и материнок Topton. Выбрана Topton N22 Mini-ITX (~$200 на AliExpress): 8xSATA3, 2xM.2, 1x10Gbps + 2x2.5Gbps. Автор советует закупаться заранее, подчёркивая: "Экономика sucks, и цены отражают это".

• Обсуждение DIY NAS-билда за ~$1k (Jonsbo N3, Ryzen 5500GT, LSI 9207-8i): хвалят за цену и SAS-поддержку, критикуют за энергопотребление, отсутствие ECC и ненадёжность китайских плат (AliExpress).
• Альтернативы: Odroid H4/N100DC-ITX, б/у enterprise-железо (eBay), готовые NAS (Synology, UGREEN, QNAP), Raspberry Pi; советы по кейсам (Fractal Node 804 лучше Jonsbo), ОС (FreeBSD вместо TrueNAS).
• Проблемы: частые перестройки (каждый год?), пыль/охлаждение, отсутствие hot-swap/ECC/10G, affiliate-ссылки в блоге без раскрытия; цены HDD/SSD растут, DIY не всегда дешевле prebuilt.
• Дополнительно: переход на NVMe для скорости, tape для архива, ZFS-пулы из Barracuda, вопросы о RAM для чистого NAS и плане на пожар.

Проект Ravynos представляет собой операционную систему, созданную на базе BSD, с амбициозной целью обеспечить как исходный, так и двоичный уровень совместимости с macOS. Разработчики стремятся воссоздать знакомый пользовательский опыт macOS, но на открытой и свободной кодовой базе BSD. Это потенциально открывает возможности для запуска macOS-приложений на альтернативной платформе.

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

• Проект ravynOS стремится к совместимости с macOS на уровне исходного кода, но не бинарной совместимости, что делает его похожим на ReactOS и Wine.
• Проект использует FreeBSD как основу, но не имеет никаких бинарных компонентов macOS, что делает его похожим на ReactOS и Wine.
• Проект не имеет никаких библиотек или фреймворков macOS, что делает его похожим на ReactOS и Wine.
• Проект не имеет никаких библиотек или фреймворков macOS, что делает его похожим на ReactOS и Wine.
• Проект не имеет никаких библиотек или фреймворков macOS, что делает его похожим на ReactOS и Wine.

Автор сравнивает производительность FreeBSD, SmartOS, NetBSD, OpenBSD и Linux для статического хостинга на мини-ПК Intel N150. Тестирование проводилось с использованием nginx по протоколам HTTP и HTTPS с почти стандартными настройками без оптимизации ядра под конкретную ОС. Автор скептически относится к бенчмаркам, так как они отражают лишь специфическую рабочую нагрузку на конкретной конфигурации, но признает, что иногда полезно провести сравнительные тесты.

В предыдущих исследованиях он уже сравнивал Proxmox KVM с FreeBSD bhyve, а также Jails, Zones, bhyve и KVM на том же железе. На этот раз фокус сместился на более практическую задачу — статический хостинг. Как отмечает автор, "с выбором ОС для обычного HTTP на этом мини-ПК дело обстоит не так критично, как многие думают", но ситуация усложняется с появлением TLS. Интересно, что бездействующие bhyve VM потребляют меньше ресурсов на хосте illumos, чем на FreeBSD, что демонстрирует эффективность платформы.

• Обсуждение охватывает вопросы от производительности и безопасности до совместимости и ценовой политики, но не упоминает включение kTLS и sendfile(), что могло бы повлиять на результаты теста.
• Участники обсуждают, что тест может быть ограничен количеством доступных портов из-за особенностей TCP, и что тест может не учитывать влияние HTTP/2 и HTTP/3.
• Также обсуждается отсутствие ECC-RAM в большинстве этих систем, отсутствие 2-го M.2 слота и отсутствие 2.5G/5Gbe NIC в большинстве этих устройств.
• Участники также обсуждают ценовую политику, дефицит RAM и SSD, и то, что эти устройства могут стоить дороже из-за этого.
• В конце обсуждение смещается к тому, что эти устройства могут быть использованы как NAS или эмулятор игровых приставок, и что в некоторых случаях эти устройства могут быть использованы как десктоп системы.

Автор обнаружил удивительное поведение shebang (#!) в Unix-системах: ядро Linux, FreeBSD и OpenBSD поддерживает не только абсолютные, но и относительные пути в shebang. Например, можно использовать "#!python3", "#!bin/python3" или "#!../../../usr/bin/python3", и они будут работать при правильном расположении текущего каталога. Это поведение существует с 4.2 BSD (1983 год) и реализовано через вызов namei(), который разрешает пути так же, как и для обычных файлов.

Несмотря на потенциальные проблемы безопасности, такое поведение сохранилось во многих системах. Автор предполагает, что это связано с простотой реализации в ядре и законом Хайрума (Hyrum's Law) - вероятно, кто-то уже использует эту функциональность и зависит от неё. Интересно, что даже OpenBSD, известный вниманием к безопасности, не изменил это поведение.

• Проблема с #!/bin/bash в NixOS и других системах, где bash не в /bin, подчеркивает важность использования #!/usr/bin/env bash для переносимости.
• Обсуждение подчеркивает, что #!/usr/bin/env bash является наиболее переносимой формой, так как она использует $PATH для поиска bash.
• Несколько участников подчеркивают, что #!/bin/bash может не работать в некоторых системах, где bash не в /bin.
• Обсуждение также затрагивает безопасность: #!/usr/bin/env bash может быть опасен, если не указан полный путь, так как это может привести к запуску нежелательного кода.

Команда Swift представила предварительную версию инструментария для FreeBSD 14.3+, доступную для архитектуры x86_64. В комплекте компилятор и рантаймы Swift, необходимые для разработки. Для работы требуются зависимости: zlib-ng, python3, sqlite3, libuuid и curl. Разработчики предупреждают, что компилятор всё ещё находится в разработке и не является частью официального релиза.

Существует несколько известных проблем: некорректные отчёты Thread Sanitizer, неспособность LLDB выполнять Swift-выражения, зависание плагинов в SwiftPM, проблемы с C++ interop. Для FreeBSD 15 требуется временный workaround через установку пакета compat14x-amd64. Команда работает над добавлением поддержки aarch64 и распространением пакета для всех минорных версий FreeBSD 14. Пользователям рекомендуется сообщать о найденных ошибках на GitHub.

• Swift на FreeBSD — давно ожидаемое событие, но вопросы остаются: кто будет поддерживать порт, какие зависимости потребуются и какие части стека (например, SwiftUI) останутся проприетарными.
• Появление Swift на FreeBSD подчеркивает, что язык выходит за пределы экосистемы Apple, но при этом неясно, насколько он может быть полезен вне iOS/macOS-разработки.
• Обсуждение также затрагивает, что Swift в отличие от .NET или JVM не имеет полноценной кроссплатформенной стратегии, что ограничивает его применимость.
• Участники обсуждения отмечают, что язык не предоставляет официальной поддержки для серверной разработки, что делает его менее привлекательным для бэкенда.
• Наконец, обсуждение поднимает вопрос о том, что Swift в отличие от .NET или JVM не имеет полноценной кроссплатформенной стратегии, что ограничивает его применимость.

В FreeBSD находят способ вернуть радость в самохостинг: автор перешёл с Linux, устав от сложностей, и нашёл в BSD простоту, стабильность и отличную документацию.

Ключевые моменты:

• Использует BastilleBSD для контейнеров и vm-bhyve для виртуалок, несмотря на начальную путаницу.
• Ценит долгосрочную совместимость: решения десятилетней давности работают и сегодня.
• Сообщество оказалось невероятно поддерживающим, помогая на каждом шагу.

Автор подчёркивает: важна не идеальная настройка, а сам процесс обучения и радость от экспериментов. Результат — возвращение к хобби-программированию с тем же азартом, что и в юности.

• Участники обсуждают преимущества и недостатки BSD-систем, включая OpenBSD, FreeBSD и производные от них, так как OPNsense и TrueNAS, в контексте самостоятельного хостинга и само-обеспечения.
• Обсуждается, что BSD-системы предлагают высокую стабильность, безопасность и простоту конфигурации, но при этом страдают от недостатка поддержки драйверов и некоторых современных технологий, таких как Docker и systemd.
• Участники делятся личным опытом, включая использование FreeBSD в качестве настольной системы и OpenBSD в качестве маршрутизатора, а также обсуждают, что такие системы могут быть использованы в качестве серверов для различных сервисов, включая Jellyfin и n8n.
• Обсуждается, что BSD-системы могут быть менее удобны для пользователей, которые привыкли к GNU-утилитам и systemd, и что это может быть препятствием для некоторых пользователей.
• Участники также обсуждают, что BSD-системы могут быть менее удобны для разработчиков, так как они могут не поддерживать такие технологии, как CUDA и Docker, что может быть важно для некоторых разработчиков.
• В конце обсуждение переходит к тому, что, несмотря на все вышеупомянутое, BSD-системы все еще имеют свою нишу и что они могут быть полезны для определенных пользователей, особенно для тех, кто ценит стабильность и безопасность.

Экспериментальный проект WSL-For-FreeBSD переносит компоненты WSL2 на FreeBSD. Он использует тот же ядро и ту же архитектуру, что и WSL2, но адаптирован для FreeBSD. Проект пока не поддерживает GPU и не реализует полную изоляцию, но уже позволяет запускать бинарники Linux в контейнере. Проект открыт и приглашает сообщество к тестированию и PR.

• Обсуждение началось с замечания, что названия вроде «Windows Subsystem for Linux» на самом деле перепутаны и должны бы быть «Linux Subsystem for Windows».
• Участники обсудили, что Microsoft вместо «Windows Services for UNIX» предлагает «Windows Subsystem for Linux» и теперь «Windows Subsystem for FreeBSD».
• Участники обсудили, что FreeBSD используется в Netflix, PS4/PS5, WhatsApp до покупки Facebook и pfSense, но не настолько популярен на десктопе.
• Участники обсудили, что FreeBSD не поддерживает Adobe, Microsoft Office и игры, что делает его непрактичным для десктопа.
• Участники обсудили, что FreeBSD не поддерживает Wi-Fi на ноутбуках Dell, что делает его непрактичным для десктопа.

Изучение x86-64 ассемблера через создание GUI с нуля

Филипп Гольтье

• Работы
• Теги
• Резюме

⏴ Назад ко всем статьям

Опубликовано 31.05.2023

Большинство считает ассемблер языком для учебных программ или оптимизации отдельных функций. Но что если написать на нём полноценную GUI-программу? Это будет «Hello World» для графического интерфейса, но всё же. Результат:

Меня вдохновила мысль: современные бинарные файлы часто весят 30+ МБ — а насколько маленьким может быть GUI? Оказалось, всего около 1 КБ!

Я не эксперт в ассемблере или X11, но надеюсь дать понятное руководство для начинающих. Ошибки? Сообщайте в Github.

Примечание: Аутентификация в X11 опциональна, но некоторые серверы (например XWayland) требуют её. Здесь она опущена.

Что потребуется?

Используем ассемблер nasm — простой, кроссплатформенный и быстрый. Для GUI возьмём X11, так как он работает без внешних библиотек. На Wayland должно работать через XWayland, на macOS — с XQuartz (но потребуется формат macho64 и иные значения системных вызовов).

Разница между ОС сводится к значениям системных вызовов. Для Linux укажем свои, для FreeBSD — другие, используя макросы nasm:

%ifdef linux
  %define SYSCALL_EXIT 60
%elifdef freebsd
  %define SYSCALL_EXIT 1
%endif

Компилируем на Linux, отправляем другу на FreeBSD — и оно работает!

Linux — единственная ОС со стабильным ABI. Другие могут его ломать, но для базовых вызовов это редкость.

Основы X11

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

Обычно используют libX11 или libxcb, но мы сделаем всё сами. Сервер может быть хоть на другом конце света — это не важно для клиента.

• Обсуждение началось с проекта по изучению ассемблера x86-64 через написание GUI "с нуля", но многие отметили, что использование X-сервера не является истинным "с нуля".
• Несколько пользователей поделились личным опытом изучения ассемблера через различные проекты: написание приложения на GTK, работу с микроконтроллерами PIC и создание собственного виртуального процессора.
• Было высказано мнение, что работа с "сырым" X-протоколом не сложна, но утомительна из-за его асинхронной природы и необходимости сериализации/десериализации запросов.
• Участники дискутировали о том, что на самом деле означает термин "с нуля" (from scratch), от сравнительно простого использования API до создания всей системы самостоятельно.
• В качестве сравнения был приведен пример с Win32, где создание GUI заключается в основном в заполнении структур и вызове функций.
• Было отмечено, что проект, несмотря на спорное определение "с нуля", является более сложным и продвинутым, чем многие аналогичные попытки.
• Один из комментаторов указал на проблему с поддержкой высокого разрешения в XQuartz для пользователей macOS.

• Кто-то в восторге от Podman: нет лицензий, rootless, systemd-интеграция, podman generate kube.
• Кто-то страдает: старые версии в Ubuntu, тормоза, сетевые сбои, SELinux, UID-маппинг, compose не докручен.
• Docker упрекают в daemon-root и тяжёлом демоне, но хвалят за «просто работает» и DX.
• Часть вообще ушла в FreeBSD Jails, OrbStack, Colima или bash-скрипты на VPS.
• Вывод: Podman годится, если готовы поборотьься; иначе остаёмся на Docker или ищем третий путь.

Краткие заметки об «амазонском» лидерстве

Customer Obsession
Хороший принцип, но его часто упрощают: «начать с клиента» ≠ «спросить, что он хочет». Ранний AWS делал крутые строительные блоки (EC2), а после 2012-го перешёл к «делать то, что просят». Это шаг назад. Клиенты не просят Paxos-as-a-service, но именно он им нужен, чтобы быть отказоустойчивыми. AWS стоит вернуться к выпуску внутренних блоков, а не ждать запросов.

Ownership
Принцип узок: надо думать не только о компании, но и об экосистеме. Пример — разработка стандартов прерываний для bhyve, хотя Amazon его не использует. Внутри Amazon сильные «стены»: команды не знают, что делают соседи, поэтому «действовать от лица всей компании» невозможно. Нужно ломать силосы.

Bias for Action
«Многие решения обратимы» ≠ «обратимы без потерь». Половинчатые сервисы подрывают доверие клиентов; память о провале живёт годами. Как офицер безопасности FreeBSD, я чаще говорил «стоп» и не выпускал сломанный патч, чем спешил. Доверие важнее скорости.

• Участники устали от «принцип-фатиги»: компании декларируют красивые лидерские принципы, но быстро от них отступают при первом давлении.
• «Leaders are owners» выглядит выгодно для акционеров, но невыгодно для сотрудников, получающих лишь крошечные доли RSU.
• Многие считают, что после массовых сокращений 2022 г. и жёсткого возврата в офисы принципы Amazon, включая «Strive to be Earth’s Best Employer», стали звучать лицемерно.
• Часть бывших сотрудников утверждает, что внутри компании принципы используют как инструмент контроля и оправдания низкой производительности, а не как ориентиры для роста.
• Общий вывод: формальные принципы давно превратились в «операционные гайдлайны» или пропаганду, тогда как реальной целью остаётся «make money».

• bcachefs переведён в статус externally maintained — Линус отметил, что новые изменения в mainline маловероятны, но немедленного удаления файловой системы из ядра не планируется.
• Суть конфликта: не лицензия и не технические проблемы, а личные разногласия Линуса и других разработчиков с автором bcachefs Кентом Оверстритом.
• Возможные сценарии
  • Найти нового мейнтейнера, который будет выступать посредником между Кентом и ядром.
  • Риск: такой человек может выгореть, повторив конфликт «по доверенности».
  • Альтернатива — форк ядра без участия Кента, но Линусу это, судя по всему, неинтересно.
• Позиция Кента: он не хочет перекладывать ответственность на коллег-разработчиков, чтобы не потерять ещё одного инженера, и настаивает на контроле качества релизов, так как сам обрабатывает большинство баг-репортов.

• Btrfs по-прежнему не догнал ZFS по надёжности и функционалу, а уход Josef Bacik из Meta усиливает тревогу за его будущее.
• bcachefs остаётся в ядре, но из-за конфликта Kent Overstreet с процессом слияния патчей его обновления теперь могут идти вне основного дерева (DKMS/сторонние репозитории).
• Участники обсуждают высокий «bus-factor» bcachefs (разработка почти одним человеком) и сравнивают ситуацию с ZFS, который стабильно работает на FreeBSD и некоторых Linux-дистрибутивах.
• Некоторые пользователи рассматривают переход на FreeBSD или возврат к проверенным схемам LVM+XFS из-за нестабильности btrfs и проблем bcachefs.

Цель
Адаптировать планировщик ULE для гибридных CPU (P- и E-ядер Intel, big.LITTLE ARM), позволяя выбирать приоритет: максимальная производительность, энергоэффективность или баланс.

Проблема
Традиционные cpuset(1) лишь ограничивают, какие ядра разрешены, но не говорят, какие из них предпочтительны. Прямое связывание политик с масками cpuset приводит к жёсткой фиксации и конфликтам при наследовании.

Решение

• Ввести политики как отдельный параметр, привязанный к cpuset.
• Дочерние cpuset могут лишь ужесточать политику, а не расширять.
• Поддержать шкалу «энергоэффективности» 0–100:
  0 = все P-ядра, 100 = только E-ядра, промежуточные значения задают пропорцию.
• Позволить админу задавать разные политики для разных разделов системы (джейлы, cgroup, NUMA-домены).

• Архитектура P- и E-ядер красива на словах, но на практике планировщик быстро теряет контроль: короткие задачи могут быть латентно-чувствительными, а длинные — срочными.
• Пользователи сравнивают ситуацию с провалом AMD Bulldozer: «много ядер, посредственная производительность» и ощущение непредсказуемости.
• Некоторые ушли на Linux, где можно вручную управлять распределением на гетерогенных CPU.
• Предлагают использовать nice-уровни и источник питания (AC/батарея) как простые эвристики для выбора ядра.
• Многие требуют ручного контроля: «дайте мне кнопку “сейчас всё важно” или “выжми максимум времени автономии”».
• Утверждение, что «все новые Intel уже гибридные», оказалось преувеличением: i3, Pentium, Celeron и часть Xeon всё ещё без E-ядер.