Joshua Blais глубоко интегрирует Emacs в свою рабочую среду, используя его для практически всех задач, кроме работы с видео. Он выбрал Hyprland в качестве оконного менеджера, отмечая его простоту настройки и отсутствие лагов в Wayland-режиме, в отличие от GNOME, где приходилось запускать Emacs в X11. Его цель — создать бесшовную среду, где мысли мгновенно превращаются в действия.

Автор рассматривал EXWM как оконный менеджер, но отказался от идеи из-за однопоточности Emacs (риск зависания всей системы) и привязки к X11, в то время как развитие Linux движется к Wayland. Для ускорения workflows он создал кастомный лаунчер на Go, который ускорил его работу в 10 раз. Текущая настройка включает vterm в качестве терминала по умолчанию, универсальный лаунчер, org mode для заметок, менеджер паролей, почту, чтение лент и музыку — всё внутри Emacs.

• Спор о влиянии инструментов на творчество: одни утверждают, что свобода от инструментов раскрывает потенциал профессионалов, другие считают это заблуждением, подчеркивая важность качества инструментов.
• Критика дистрибутивов типа Doom Emacs и Spacemacs: пользователи отмечают их полезность для новичков, но указывают на ограничения при глубокой кастомизации и конфликт с личными предпочтениями.
• Технические ограничения Emacs: обсуждение проблем с EXWM (конфликт клавиш, однопоточность) и TRAMP для удаленной разработки, а также сравнение с современными редакторами вроде Helix.
• Философия кастомизации: Emacs ценится за возможность полной настройки через Elisp, но это требует времени и усилий, что отпугивает некоторых пользователей.
• Альтернативы и будущее: предложения о создании единого универсального редактора, критика текущей модели с множеством "окон в окнах" и поиск баланса между простотой и гибкостью.

Выпущены исправления для трех критических уязвимостей в X.Org X server и Xwayland. Обновления xorg-server-21.1.19 и xwayland-24.1.9 исправляют проблемы, существовавшие в предыдущих версиях. Все три уязвимости (CVE-2025-62229, CVE-2025-62230 и CVE-2025-62231) были обнаружены Jan-Niklas Sohn при сотрудничестве с Trend Micro Zero Day Initiative.

Первая уязвимость связана с use-after-free при создании XPresentNotify структур, вторая - с некорректным удалением Xkb клиентских ресурсов, а третья - с переполнением значения в XkbSetCompatMap(). Две из этих проблем существуют с версии X11R6, что подчеркивает их серьезность. Все исправления уже доступны в репозиториях, и пользователям рекомендуется немедленно обновить системы для предотвращения потенциальных атак.

• В обсуждении поднимается вопрос о том, что X11/X.Org уязвим к трем недавно обнаруженным уязвимостям, и что это может быть последней каплей, которая убедит окончательно перейти на Wayland.
• Участники обсуждают, что X11 не имеет никаких механизмов безопасности, и что это не может быть исправлено без полной переработки.
• Некоторые участники высказывают мнение, что X11 устарел и что усилия по его поддержке были бы лучше направлены на другие проекты.
• Также обсуждается, что X11 не может быть защищен от вредоносного клиента, и что это не может быть исправлено без полной переработки.

Fynedesk — это полноценная десктопная среда для Linux/Unix, построенная на основе инструментария Fyne. Она предлагает минималистичный интерфейс с акцентом на простоту и производительность, используя Go для кросс-платформенной разработки. Проект включает стандартные компоненты: панель задач, меню приложений, управление окнами и настройки темы, что делает его готовым к повседневному использованию.

Ключевое преимущество — лёгкость кастомизации и расширения благодаря модульной архитектуре и чистой кодовой базе на Go. Это позволяет разработчикам быстро адаптировать или дополнять функциональность под свои нужды. Fynedesk позиционируется как альтернатива тяжёлым средам вроде GNOME или KDE, особенно для ресурсоограниченных систем или пользователей, ценящих скорость и минимализм.

• Обсуждение фокусируется на поддержке Wayland в FyneDesk, с ожиданием её реализации в будущих версиях и критикой текущей зависимости от X11.
• Участники отмечают потенциал проекта как современной кроссплатформенной среды на Go, но выражают озабоченность по поводу скорости разработки и активности коммитов.
• Поднимаются вопросы о мотивации и статусе разработки (хобби, коммерческий или академический проект), а также о простоте использования и настройки.
• Обсуждаются технические аспекты: производительность, возможность кастомизации, сравнение с другими средами и работа на мобильных устройствах.
• Некоторые пользователи выражают скептицизм, считая проект устаревшим или игрушечным без поддержки Wayland, в то время как другие защищают его и призывают к поддержке.

System76 выпустила бета-версию Pop!_OS 24.04 LTS с новой средой рабочего стола COSMIC, полностью разработанной внутри компании. Ключевые изменения включают замену стандартных GNOME-приложений на COSMIC-аналоги: Files, Terminal, Text Editor и Media Player, а также обновлённый магазин приложений COSMIC Store. Для установки требуется отключить Secure Boot в BIOS, рекомендуется минимум 4 ГБ ОЗУ и 16 ГБ места.

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

• Пользователи положительно оценивают новый рабочий стол Cosmic DE за его функциональность, включая панель на всех экранах и улучшенное управление окнами, по сравнению с GNOME.
• Некоторые пользователи выражают скептицизм относительно готовности Cosmic DE к релизу, отмечая проблемы с драйверами Nvidia, отсутствие поддержки Secure Boot и ARM64, а также сыроватый интерфейс.
• Многие пользователи успешно используют Pop!_OS на старом оборудовании (например, MacBook Pro 2014 года), хотя иногда требуется ручная настройка Wi-Fi и других компонентов.
• Обсуждаются преимущества Pop!_OS, такие как предустановленные драйверы Nvidia в Live ISO и режим тайлинга, а также сравнивается Cosmic с другими средами, такими как Hyprland и Sway.
• Высказываются опасения, что небольшой команде System76 может не хватить ресурсов для долгосрочной поддержки собственной среды рабочего стола, и отмечается медленный темп разработки.

Изучение 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.

GTK1
Классическая библиотека GUI GTK1 для Windows, Linux, macOS.
Языки: C/C++.
108 коммитов, 1 ветка, 0 тегов.

• Кто-то всё ещё поддерживает GTK 1.2: CinePaint и Lazarus используют его как «стабильную» базу, но приходится собирать из исходников — ни одна современная дистра, кроме Slackware, не поставляет пакеты.
• Совместимости между GTK1 и GTK2/3/4 нет: API ломают регулярно, что участники называют «визитной карточкой GNOME».
• GTK1 ценят за лёгкость, быструю работу по удалённому X11 и простоту статической линковки; минусы — нет юникода, антиалиасинга, fontconfig, только X11 core-шрифты.
• GTK2 тоже считают «мертвым»: 30-40 DLL на Windows, медленный remote-X, а тяжёлый GTK3/4 воспринимают как «ад в корзине».
• Утилиты вроде Glade давно не обновлялись, примеры в доках течёт памятью, а «лёгкой» сборки GTK2 никто не делает.

Запускаю полноценный Linux-десктоп в Docker — просто потому что могу

Автор: Ali Haider

Docker считается исключительно для CLI-сервисов, но я решил разместить в контейнере полноценный графический Linux. Зачем? Из чистого любопытства и желания проверить границы технологии.

Почему не VirtualBox или dual-boot?
Хотелось получить Linux, который живёт рядом с Windows без перезагрузок и разделов. Казалось, что за пару дней подниму GNOME/KDE в контейнере, но эксперимент затянулся на четыре дня и превзошёл все ожидания.

Что получилось
На Windows 10 через Docker удалось запустить полноценный рабочий стол. Проект стал жёстким crash-курсом по X11, PulseAudio, GPU-пасsthrough и сетевым трюкам, но в итоге всё работает: окна Linux-приложений появляются поверх Windows, звук идёт, файлы доступны.

• Участники делятся опытом запуска полноценных Linux-десктопов в Docker/LXC: Arch + noVNC, Selkies + KDE, linuxserver/webtop, SkiffOS.
• Обсуждают производительность: 70 % от нативной при web-VNC, лучше через Sunshine или xrdp с аппаратным ускорением.
• Появляются идеи: эфемерные браузеры через Tailscale+Mullvad, Twitch/Discord-Plays-Pokemon, тесты из разных стран.
• Кто-то предпочитает LXC/LXD или systemd-nspawn, чтобы не мучиться с systemd внутри OCI-контейнеров.
• Вспоминают исторические проекты: Jess Frazelle, Samsung DeX, WSL2 + MobaXterm, MATLAB-контейнер.

На Linux Ctrl-C/Ctrl-V в терминале не работают, потому что Ctrl нужен для управляющих кодов. Приходится жать Ctrl+Shift+C/V. К 2025 году появится универсальное решение без лишнего ПО: старые коды клавиш Copy и Paste, которые Linux «знает» с древности.

Как это работает

1. Клавиатура
   Программируемые клавиатуры (System76 Launch, Framework 16, ZSA Moonlander, Keychron Q10 и др.) позволяют назначить на любую клавишу слой, где C = Copy, V = Paste. Для активации слоя удерживается модификатор (например, «Raise» на моей Corne).

2. Прошивка и конфигураторы
   Производители дают свои утилиты (System76 Keyboard Configurator), а Vial поддерживает множество моделей. В слое можно вывести Copy/Paste на C/V, стрелки на домашний ряд и прочие удобства.

3. ПО Linux
   Приложения опираются на GUI-тулкиты GTK и Qt.

   • GTK добавил поддержку Copy/Paste-кодов в январе 2025.
   • Qt внедрит их в версии 6.10 (сентябрь 2025).

Совокупность программируемого «железа» и обновлённых тулкитов даст единые горячие клавиши Copy/Paste во всех приложениях Linux без дополнительных твиков.

• Участники жалуются на разнообразие клипбордов в Linux (X11, Vim, tmux) и их несогласованность.
• В терминалах приходится добавлять Shift к Ctrl-C/Ctrl-V, что ломает мышечную память и вызывает ошибки.
• Apple решает конфликт отдельным Cmd-ключом, но даже там приложения перехватывают сочетания непредсказуемо.
• Многие используют альтернативы: Ctrl/Shift-Insert, выделение + средняя кнопка мыши, ремап клавиш, покупку программируемых клавиатур.
• Единого механизма объявления и настройки шорткатов в Linux нет, поэтому Chrome и другие приложения игнорируют системные привязки.

StarDict — кроссплатформенный словарь GPLv3 — при работе в X11 по умолчанию пересылает выделенный пользователем текст по нешифрованному HTTP на два китайских сервиса: YouDao и dict.cn.

Проблема обнаружена Винсентом Лефевром 4 августа 2025 года при подготовке к Debian 13. Пакет stardict-plugin, который ставится автоматически, содержит плагин YouDao. Функция «scan» (включена по умолчанию) отслеживает выделение мышью и отправляет текст на серверы без шифрования.

На Wayland уязвимости нет: система блокирует чтение чужих выделений, но и «scan» не работает.

Сопровождающий Debian Сяо Шэн Вэнь считает поведение допустимым: функции можно отключить. Лефевр возражает: конфиденциальные возможности не должны быть активны по умолчанию.

Описание пакета упоминает «scan», но не говорит, что YouDao — онлайн-сервис. Сяо предложил вынести сетевые плагины в отдельный пакет, но сомневается в необходимости.

Аналогичные проблемы сообщались в 2009 и 2015 годах; тогда отключили сетевые словари по умолчанию, но плагин YouDao (добавлен в 2016) игнорирует эту настройку.

• Пакет StarDict по умолчанию отправляет выделенный текст на китайские серверы по нешифрованному HTTP.
• Мейнтейнер Debian отмахнулся: «в описании пакета всё написано, RTFM».
• Пользователи возмущены: словарь можно было сделать полностью локальным (≈ 400 МБ), а поведение — опциональным.
• Уязвимость годами игнорировалась, баг-репорты закрывались как «небаг».
• Сообщество требует исключить StarDict из репозиториев и пересмотреть политику мейнтейнеров.

Как приложение получает фокус в Wayland
В X11 окно могло «захватить» внимание само; в Wayland это невозможно. Приложение может лишь получить фокус, если композитор одобрит запрос. Для этого используется протокол XDG Activation.

1. Приложение-источник (например, мессенджер) запрашивает у композитора токен активации.
2. Токен передаётся целевому приложению через переменную окружения XDG_ACTIVATION_TOKEN или поле activation-token в DBus.
3. Получив токен, приложение просит композитор активировать своё окно.
4. Композитор проверяет подлинность: наличие токена, серийный номер события, ID приложения и т.д. При сомнении запрос отклоняется.

Готовые решения в KDE/Qt

• QWindow::requestActivate() сама использует токен из окружения или запрашивает новый.
• OpenUrlJob, ApplicationLauncherJob, KDBusService уже умеют работать с токенами.
  Благодаря этому большинство KDE-приложений работают без изменений.

Почему X11 не идеален
У KWin-X11 была «защита от кражи фокуса», но она опиралась на эвристики и могла быть обойдена.

Тестируем правильность
В свежем KWin включите «Extreme»-режим предотвращения кражи фокуса: окно поднимется только при валидном токене. За последние дни исправлены:

• Dolphin терял токен при новом запуске;
• KRunner, Kickoff и прочие плазмоиды не запрашивали токен;
• LayerShell-Qt теперь читает переменную и запрашивает активацию при показе;
• привилегированные клиенты (Plasma, KGlobalAccel) могут получать токены;
• нажатия модификаторов больше не считаются «пользовательским взаимодействием».

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

• Пользователи рады, что Wayland запрещает приложениям «воровать» фокус, в отличие от X11/macOS/Windows, где авто-обновления и всплывающие окна прерывают работу.
• Некоторые жалуются: из-за новых правил пароли и другие важные диалоги прячутся под окнами, пока не всё ПО перейдёт на XDG Activation.
• Дискуссия о том, кто должен решать передачу фокуса: само приложение, оконный менеджер или пользователь.
• Название «Window Activation» ввело в заблуждение: многие ждали статью о лицензировании Windows.