Команда 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-ядер.