Perkeep (ранее Camlistore) — это набор открытых форматов, протоколов и программного обеспечения для моделирования, хранения, поиска, обмена и синхронизации данных в пост-ПК эру. Система позволяет навсегда сохранять любые данные — от файлов и твитов до видеофайлов объемом 5 ТБ, с доступом через телефон, браузер или FUSE-файловую систему. Проект активно развивается, и хотя он уже полезен для технических пользователей, стоит быть готовым к ошибкам и незавершенным функциям.

Основные принципы Perkeep: полный контроль пользователя над данными, открытый исходный код, паранойяльное отношение к конфиденциальности (все приватно по умолчанию) и отсутствие единой точки отказа. Разработчики стремятся обеспечить сохранность данных на протяжении 80 лет. Последний релиз — версия 0.12 "Toronto", выпущенная 11 ноября 2025 года. Для технических пользователей доступны инструкции по установке, а также видео-демонстрации с конференций LinuxFest Northwest 2018.

• Обсуждение в основном вращается вокруг Perkeep (Perkeep), его философии «хранить всё навсегда» и причин, по которым проект не стал мейнстримом.
• Участники сравнивают Perkeep с традиционной файловой системой, поднимают вопросы о практичности и удобстве использования.
• Некоторые упоминают альтернативы вроде git-annex, ArchiveBox и SingleFile, но консенсуса по поводу «серебряной пули» нет.
• Обсуждение также затрагивает болевые точки: отсутствие у Perkeep интеграций с телефоном и облачными сервисами, а также его способности обрабатывать большие объемы данных.
• В целом, участники сходятся во мнении, что идея «вечного хранилища» остается привлекательной, но ее реализация в виде Perkeep не решает насущные проблемы, и сообщество в целом скептически настроено по отношению к перспективе «единой платформы для всей вашей цифровой жизни».

После прививки от гриппа автору предложили 24-часовой мониторинг давления с устройством Microlife WatchBP O3, которое автоматически измеряет давление каждые 30 минут днём и 60 ночью. Обнаружив micro-USB порт на устройстве, он решил анализировать данные без использования официального Windows-приложения WatchBP Analyzer. Устройство распознавалось в Linux как hidraw, но для доступа к данным потребовался запуск Windows в виртуальной машине через Gnome Boxes с перенаправлением USB-устройства.

Анализируя трафик между хостом и устройством через Wireshark и usbmon, автор обнаружил, что данные передаются в 32-байтных пакетах. Первый байт указывает количество значащих битов в пакете, третий байт кодирует систолическое давление, четвёртый — диастолическое, а пятый — пульс. Например, пакет 05 0a 89 71 43 9b соответствовал давлению 137/113 и пульсу 67. Однако полной расшифровки протокола не удалось — остались неопределёнными второй и шестой байты, а также отсутствовали метки времени и данные об Oscillometric signal peak pressure (OPP).

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

Knokke представляет собой новый высокоскоростной сканер 35 мм пленки, который позиционируется как "новая эра сканирования". Устройство предлагает впечатляющие характеристики: разрешение 4064 DPI, динамический диапазон 120 дБ и глубину цвета 48 бит, при этом способно отсканировать всю катушку всего за несколько минут. Сканирование происходит с помощью кастомной оптики и современного сенсора, что обеспечивает высочайшее качество при доступной цене.

Сканер работает на собственном программном обеспечении Korova — легком приложении на C++, нативном для Linux, macOS и Windows. Это позволяет отказаться от устаревших ПК и использовать современный plug-and-workflow. Каждому кадру можно задать индивидуальные настройки, которые повторяются при последующих сканированиях для консистентных результатов. Цена запуска составит €999, включая и сканер, и программное обеспечение.

• Стоимость сканера Knokke составляет €999, что вызывает сравнение с ценой на подержанные DSLR-установки и вызывает обсуждение ценообразования.
• Отсутствие примеров сканов и отсутствие ИК-сенсора для удаления пыли и царапин вызывает критику.
• Обсуждается, что цена может быть оправдана для энтузиастов, которые ценят дизайн и удобство использования.
• Некоторые участники обсуждения выражают сожаление, что сканер не поддерживает 120 формат, а также отсутствие автоподатчика.
• Участники также обсуждают, что стоимость может быть оправдана для тех, кто ищет высокое качество сканирования и готов заплатить за него.

Автор исследует, сколько усилий требуется для реализации собственных примитивов BEAM, создавая упрощенную версию виртуальной машины на Elm. Используя стиль передачи продолжений (CPS), он избегает необходимости писать парсер, CLI и другие компоненты полноценного компилятора, сосредоточившись на ядре системы. Этот подход позволяет сосредоточиться на основных концепциях, таких как планировщик, процессы и их взаимодействие.

Начав с базовых инструкций End (завершение программы) и Work (имитация выполнения работы), автор добавляет примитив Spawn для создания процессов, что требует изменения структуры планировщика для отслеживания нескольких процессов. В планах реализация обмена сообщениями, выборочного приема и связывания процессов для создания деревьев надзора. Ключевой особенностью подхода является использование CPS для упрощения реализации, где продолжения обрабатывают управление потоком выполнения.

• Обсуждение в основном вращается вокруг BEAM: его происхождение, ограничения и будущее.
• Участники обсуждают, что BEAM не переносим между дистрибутивами Linux, в отличие от JVM, и требует компиляции из исходников.
• Поднимается вопрос о том, что написание статьи не объясняет читателям, что такое BEAM, и что это значит для них.
• Некоторые участники предлагают использовать Nix или статически слинкованный BEAM для решения проблемы портируемости.
• Также обсуждается, что исходный код BEAM доступен, и что ранние версии BEAM, возможно, были бы полезны для изучения.

В NetBSD отсутствует полноценная технология sandboxing, в отличие от FreeBSD (jails) и Linux (namespaces). Существующий chroot считается слабым механизмом изоляции, так как ограничивает только представление файловой системы, но не изолирует сеть, IPC и монтирование. Предыдущие попытки реализации изоляции на уровне ядра с помощью инструментов gaols, mult и netbsd-sandbox не были интегрированы в систему.

В рамках Google Summer of Code 2025 планируется реализовать механизм, подобный Linux namespaces, используя bubblewrap. Проект фокусируется на двух типах namespace: UTS (для управления именем хоста) и mount (для изоляции файловых систем). Реализация будет использовать системные вызовы unshare или clone, а в ядре NetBSD - подсистему kauth для управления авторизацией и жизненным циклом credential. Это позволит не только добавить изоляцию приложений, но и улучшить совместимость с Linux-бинарниками через существующий compat_linux.

• Bubblewrap — основа песочницы Flatpak, используется для изоляции приложений (например, Claude Code/Codex/Gemini CLI) с контролем доступа к системе.
• NetBSD выделяется полной бит-в-бит воспроизводимостью бинарников и вендорингом GCC, что обеспечивает воспроизводимость всей цепочки инструментов; Golang также обеспечивает воспроизводимость реестра пакетов.
• Полные окружения рабочего стола (labwc, KWin, Plasma) могут запускаться через bwrap с привязкой устройств и временных файлов, с возможностью ограничения доступа.
• Sandbox-инструменты (bubblewrap, firejail) имеют ограничения в Linux, особенно на десктопе; AppArmor предлагает профили с автоматическим определением разрешений.
• Guix и FreeBSD (v15) также рассматриваются в контексте воспроизводимости сборок и безопасности.

• Родители обсуждают, какой дистрибутив и подход лучше всего подойдет для детей: от Raspberry Pi с Kano-образовательными наборами до полноценных ноутбуков с Linux, при этом учитывая, что дети могут захотеть играть в игры, и что важно не отпугнуть их слишком сложной ОС.
• Важно не только обучение, но и безопасность: обсуждаются такие инструменты, как Pi-hole для фильтрации контента, и то, что дети могут захотеть играть в игры, и что важно не отпугнуть их слишком сложной ОС.
• Обсуждается, что важно дать детям возможность «сломать» систему и научиться её чинить, но при этом не отпугнуть их.
• Участники делятся опытом, что дети могут захотеть играть в игры, и что важно не отпугнуть их слишком сложной ОС.

writerdeckOS - это минималистичная ОС, превращающая ноутбуки и Chromebook в устройства для чистого письма без отвлекающих факторов. Основанная на Debian Linux, она загружается напрямую в текстовый редактор Tilde, предлагая только необходимое для написания текстов. ОС легковесна и позволяет превратить старые или недорогие ноутбуки в специализированные машины для писателей.

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

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

52-летняя магнитная лента, обнаруженная в архивах, может содержать утерянные ранние версии Unix, включая код, предшествовавший официальному релизу в 1971 году. Найденная в коллекции Bell Labs, лента хранит копию версии Unix 0, которая считается "святым Граалем" для историков вычислительной техники. Успешное восстановление данных с этого артефакта позволит проследить эволюцию ключевых компонентов ОС, таких как файловая система и ядро, и заполнить пробелы в истории Unix, повлиявшей на современные операционные системы.

Специалисты из Computer History Museum и Unix Heritage Society ведут сложный процесс восстановления данных с деградированной ленты, используя специализированное оборудование. По словам одного из экспертов, "эта лента — как цифровая Декларация независимости для Unix". Если восстановление пройдет успешно, это станет первым случаем извлечения работающего кода из столь ранней версии Unix, предоставив уникальную возможность изучить "первобытный код", сформировавший основу для Linux, macOS и других систем.

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

YouTube удалил туториалы по обходу требований Windows 11 с канала CyberCPU Tech, утверждая, что они "создают риск серьезного физического вреда или смерти". Оба видео - об установке Windows 11 с локальным аккаунтом и обходе аппаратных требований - получили предупреждения о нарушении правил. Первое обжалование было отклонено за 45 минут, второе - всего за 5 минут, что вызвало вопросы о прозрачности процесса модерации.

Автор канала подозревает либо избыточно усердную ИИ-модерацию, либо возможное вмешательство Microsoft. YouTube не предоставил четких объяснений своим действиям, оставляя создателей контента без возможности защиты. Этот случай стал еще одним примером того, как крупные платформы удаляют технический контент без достаточных оснований, оставляя создателей без ресурсов для оспаривания решений.

• YouTube удалил видео о ручной установке Windows 11, сославшись на "риск физического вреда", что вызвало критику цензуры.
• Пользователи сочли причину удаления абсурдной и указали на неэффективность автоматизированной модерации.
• Удаление спровоцировало миграцию пользователей на Linux и macOS, а также эффект Стрейсанд (усиление интереса к удалённому контенту).
• Видео были восстановлены после апелляции, но корпоративная политика цензуры осталась предметом спора.
• Обсуждение затронуло недоверие к платформам и необходимость регулирования корпораций.

Жан-Баптист Кемпф, президент и основной разработчик VLC, получил Европейскую премию SFS 2025 на SFSCON за свою долгосрочную преданность проекту. VLC, начавшийся как студенческая инициатива в 1996 году, превратился в один из самых широко используемых медиаплееров с миллиардами пользователей по всему миру. Когда проект был на грани исчезновения после выпуска оригинальных разработчиков, Кемпф взял на себя руководство и преобразовал его в незаменимый медиаплеер, который мы используем сегодня.

Маттиас Киршнер, президент FSFE, отметил, что для многих пользователей проприетарных операционных систем VLC стал первым свободным программным обеспечением, которое они когда-либо устанавливали. В своей речи Кемпф выразил честь получению награды и поблагодарил команды VideoLAN и FFmpeg за их работу, часто совершаемую с малым признанием. Европейская премия SFS, учрежденная в 2023 году, признает людей, внесших значительный и устойчивый вклад в продвижение свободного программного обеспечения в Европе.

• VLC исторически критичен для воспроизведения видео благодаря широкой поддержке кодеков, особенно в 2000-х, и остается популярным на мобильных устройствах и Windows.
• Основатель проекта Жан-Батист Кемпф получил признание за отказ многомиллионного предложения о продаже, чтобы сохранить проект открытым и без "вшивания" рекламы.
• На Linux VLC уступает mpv/Celluloid для продвинутых пользователей, но остается удобным решением для новичков и систем с устаревшим оборудованием.
• Проект вносит значительный вклад в экосистему через ffmpeg и разработку технологий вроде низколатентного стриминга Kyber, несмотря на критику интерфейса и функционала.

Filip Pizlo выпустил проект Fil-C, добавляющий проверку безопасности памяти в clang и включающий параллельный сборщик мусора. Инструмент демонстрирует высокую совместимость с существующим кодом, позволяя с минимальными исправлениями собирать полный Linux userspace. По измерениям, производительность составляет 1-4x (и более широкий диапазон по другим тестам), что для многих рабочих нагрузок является приемлемым. Проект основан на долгой линии исследований в области безопасности памяти, включая работы самого автора в Apple, где некоторые предыдущие итерации уже используются в производстве.

Несмотря на преимущества, Fil-C имеет ограничения: он динамически, а не статически предотвращает ошибки, программы все еще могут аварийно завершаться, есть накладные расходы на память (3-6x), и он не решает проблему гонок данных. Автор отмечает интересную возможность применения - проверки границ Fil-C могут сделать указательный код на C безопаснее, чем небезопасный Rust, и предлагает идею адаптации для компиляции небезопасных блоков Rust с дополнительными проверками.

• Почти все программы имеют пути, которые могут привести к краху, но это не означает, что они будут достаточно часто встречаться, чтобы быть проблемой.
• Fil-C обеспечивает безопасность памяти, но требует сборщика мусора и может быть медленнее, чем Rust.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.

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, но это требует времени и усилий, что отпугивает некоторых пользователей.
• Альтернативы и будущее: предложения о создании единого универсального редактора, критика текущей модели с множеством "окон в окнах" и поиск баланса между простотой и гибкостью.

Представлен bluetui - текстовый интерфейс (TUI) для управления Bluetooth-устройствами в Linux. Инструмент предлагает удобное консольное решение для взаимодействия с Bluetooth без необходимости использования графических интерфейсов. Разработанный на Python, проект обеспечивает интуитивное управление подключениями, сканированием устройств и настройками через текстовый интерфейс.

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

• bluetui и подобные инструменты демонстрируют, что TUI-утилиты могут быть не только удобными, но и важными для решения повседневных задач, таких как управление Bluetooth-устройствами, что вызывает у пользователей желание попробовать Rust, даже если они раньше не рассматривали его.
• Пользователи отмечают, что такие инструменты как bluetui делают процесс решения задач более плавным и простым, и что они ценят простоту использования TUI-утилит в сравнении с GUI-альтернативами.
• Некоторые комментаторы подчеркивают важность простоты и удобства использования TUI-утилит, особенно в контексте таких инструментов как bluetui, и как это может повлиять на выбор языка программирования, так как Rust используется в таких проектах.
• Некоторые пользователи выражают желание попробовать Rust, даже если они раньше не рассматривали его, из-за таких проектов как bluetui, что подчеркивает влияние таких инструментов на выбор языка программирования.
• Некоторые комментаторы также подчеркивают, что такие инструменты как bluetui делают процесс решения задач более плавным и простым, и что они ценят простоту использования TUI-утилит в сравнении с GUI-альтернативами.

XDP (eXpress Data Path) — самый быстрый фреймворк для обработки пакетов в Linux, но изначально работал только для входящего трафика. Компания Loophole Labs обнаружила лазейку, позволяющую использовать XDP для исходящего трафика, exploiting уязвимость в том, как ядро Linux определяет направление пакета. Их решение обеспечивает в 10 раз лучшую производительность, чем текущие альтернативы, работает с существующими Docker/Kubernetes контейнерами и не требует модификаций ядра.

При обработке трафика со скоростью сотни гигабит в секунду во время миграции контейнеров и ВМ, XDP достигает скорости линии связи (line-rate), в то время как Traffic Control (TC) ограничен всего 21Gbps на исходящем трафике. Это критически важно для их инфраструктуры, где каждая CPU-единица имеет значение. Решение позволяет обрабатывать пакеты на максимальной скорости сетевого интерфейса, будь то 20Gbps или 200Gbps, без каких-либо изменений в существующей инфраструктуре.

• XDP для egress – авторы используют виртуальные интерфейсы veth, чтобы заставить XDP обрабатывать исходящий трафик, что позволяет достичь 10-кратного прироста пропускной способности по сравнению с iptables/TC, при этом оставаясь совместимым с контейнерами и Kubernetes.
• производительность и совместимость – тесты показывают, что при использовании XDP для обработки исходящих пакетов достигается 20-ти кратное увеличение пропускной способности по сравнению с iptables/TC, при этом не требуется никаких изменений в контейнере или оркестраторе.
• почему не DPDK? – авторы отмечают, что DPDK требует специального драйвера и не может быть использован в контейнерах без привилегий, в то время как XDP работает в любом месте, где работает Linux kernel, и не требует специального оборудования.
• будущее: TC и eBPF – вместо того, чтобы продолжать использовать устаревший TC, сообщество может перейти на eBPF, что позволит в будущем использовать более продвинутые функции, такие как socket фильтры, которые могут быть реализованы в пространстве имен.

Linux создаёт иллюзию непрерывного адресного пространства для процессов, собирая его постранично. Физическая RAM состоит из кадров, распределённых по всей системе, тогда как виртуальное представление — это упорядоченная линия, которую видит программа. Страницы таблицы переводят виртуальные адреса в физические кадры. При первом обращении к странице происходит page fault, и система либо заполняет кадр, либо выдаёт ошибку. При нехватке RAM неиспользуемые страницы перемещаются на диск, а при повторном доступе возвращаются обратно.

Каждый процесс владеет объектом, представляющим всё адресное пространство, разделённым на виртуальные области памяти (VMA) — непрерывные диапазоны с одинаковыми правами доступа и источником данных. Все потоки процесса разделяют это пространство. Управление происходит через mmap (резервирование области), mprotect (изменение прав) и munmap (удаление). Память выделяется лениво — при первом обращении. В /proc/self/maps можно увидеть сегменты бинарного файла, кучу, общие библиотеки и стеки потоков, а также специальные области [vdso] и [vvar] для ускорения системных вызовов. mmap создаёт обещание выделения памяти, но не выделяет страницы сразу.

• Обсуждение критикует использование фраз вроде "without the fog" как признак LLM-написанного текста и вызывает раздражение.
• Участники обсуждают блокировку сайта как угрозу и обсуждают архитектуру 6502 и виртуальную память.
• Поднимается вопрос о том, как технологии развиваются и почему мы не можем вернуться к более простым временам.

binfmt_misc — это функция ядра Linux, позволяющая системе распознавать и выполнять файлы на основе пользовательских форматов. Она расширяет стандартные возможности Linux (обычно ELF-файлы) для запуска скриптов, бинарных файлов других архитектур или пользовательских типов. Функция создает виртуальную файловую систему в /proc/sys/fs/binfmt_misc/, где регистрируются обработчики, указывающие ядру, как распознавать файлы и какой интерпретатор использовать.

Техника "Shadow SUID" использует binfmt_misc для создания скрытой бэкдоры. Атакующий регистрирует правило с флагом "C" (credentials), при котором интерпретатор запускается с правами оригинального файла. Если этот файл setuid-root, интерпретатор получает права суперпользователя. Этот метод позволяет сохранять привилегии даже после потери первоначального доступа. Интересно, что техника не задокументирована в MITRE ATT&CK и других фреймворках безопасности, что делает её практически незаметной.

Для реализации атаки нужно: проверить наличие binfmt_misc, скомпилировать интерпретатор, найти подходящий SUID-бинарный файл (например, chfn), зарегистрировать правило с магическими байтами этого файла. Когда пользователь запускает целевой бинарный файл, ядро перенаправляет выполнение на интерпретатор с повышенными привилегиями.

• Пользователи обсуждают, что binfmt_misc позволяет регистрировать обработчики для любых форматов файлов, но требует root-доступа, что делает невозможным запуск не-root-пользователем обработчика, что, как оказалось, является защитой от уязвимости.
• Аргумент о том, что это «дыра безопасности» в действительности не является таковой, поскольку требует root-доступа, и что это скорее является доказательством того, что статья упускает важную деталь.
• Участники обсуждают, что это может быть использовано для запуска кода для других архитектур через qemu-user, что делает возможным запуск контейнеров или сборку кода для других архитектур, не требуя полной эмуляции.
• Участники также обсуждают, что это может быть использовано для запуска .jar файлов и .exe (через Wine) без явного указания интерпретатора, что может быть использовано злоумышленником для создания бэкдора.
• Участники также обсуждают, что это может быть использовано для запуска кода для других архитектур без полной эмуляции, что делает возможным запуск контейнеров или сборку кода для других архитектур.

В Windows 11 25H2 исправлена давняя ошибка, из-за которой опция "Обновить и выключить" на самом деле перезагружала компьютер, а не выключала его. Эта десятилетиями существовавшая проблема вызывала путаницу у пользователей, которые ожидали полного выключения системы после установки обновлений.

Исправление стало частью обновления Windows 11 25H2 и теперь система действительно корректно завершает работу после установки обновлений. Это изменение повышает удобство использования и соответствует ожиданиям пользователей от функции "выключить", устраняя необходимость в дополнительных действиях для предотвращения автоматической перезагрузки.

• Microsoft никогда не призналась, что сломала переключатель «Update and shut down» в Windows 10, и только спустя годы признала проблему
• Пользователи годами сталкивались с тем, что «Update and shut down» просто перезагружала систему, не давая обновлениям примениться, и никакого обходного пути не предлагали
• Обсуждение выявило, что даже в 2024 году проблема всё ещё существует, а виновата в ней архитектура файловой системы Windows, которая не позволяет заменять открытые файлы
• Комментаторы отметили, что Linux и другие Unix-подобные системы сталкиваются с аналогичной дилемой, но там выбор стоит между риском несовместимости после обновления и перезагрузкой для применения обновлений
• В конце-концов, никто не может предложить, как обновлять Windows без перезагрузки, в то время как обновление ядра Linux требует лишь перезапуска служб.

Доля Linux-геймеров на Steam наконец преодолела психологически важный порог в 3%, достигнув 3.05% по данным опроса за октябрь 2025 года. Этот рост на 0.41% стал возможен благодаря устойчивому тренду и окончанию поддержки Windows 10, что побудило больше пользователей попробовать Linux. Windows по-прежнему доминирует с долей 94.84%, а macOS занимает 2.11%.

Несмотря на скромные на первый взгляд проценты, это уже миллионы пользователей. По последним официальным данным Valve за 2022 год, месячная активная аудитория Steam составляла около 120 миллионов, что означает более 4 миллионов Linux-геймеров. С учетом роста платформы и популярности Steam Deck, продающегося миллионами копиями, реальное число вероятно еще выше. Среди дистрибутивов лидирует SteamOS Holo с 27.18%, за которым следуют Arch Linux (10.32%) и Linux Mint (6.65%).

• Пользователи обсуждают переход с Windows на Linux для игр, отмечая, что большинство игр теперь работает через Proton, и что Steam Deck способствует этому.
• Некоторые упоминают, что единственное, что остаётся в Windows, — это играть в игры с античитом, так как Easy Anti-Cheat и подобные системы не работают под Linux.
• Участники также обсуждают, что, несмотря на то, что Linux-совместимость значительно улучшилась, всё ещё есть проблемы с драйверами, особенно с NVIDIA.
• Некоторые отмечают, что, несмотря на то, что Linux-совместимость значительно улучшилась, всё ещё есть проблемы с драйверами, особенно с NVIDIA.
• Также упоминается, что, хотя большинство игр теперь работает на Linux, всё ещё есть проблемы с некоторыми играми, которые не работают или имеют проблемы.

Sailfish OS — независимая мобильная ОС с открытым исходным кодом, созданная финской компанией Jolla на основе MeeGo, которую разрабатывали Nokia и Intel с инвестициями около $1 млрд. После того как Nokia отказалась от MeeGo в пользу Windows Phone, команда основала Jolla и в 2013 году представила Sailfish OS. Ключевые версии: 2.0 (2015) с планшетом Jolla, 3.0 (2018) для корпоративного сектора и 4.0 (2021) с расширенными возможностями для экосистем. ОС работает на Linux, использует QML и Qt для интерфейса, поддерживает Android-приложения и совместима с Android-чипсетами.

Sailfish OS позиционируется как альтернатива для корпораций и правительств, ищущих независимую мобильную платформу без привязки к крупным технологическим компаниям. Разработчики подчеркивают, что ОС имеет полные права интеллектуальной собственности и товарные знаки. Поддерживается глобальным сообществом, а исходный код доступен для скачивания. Благодаря использованию Qt5 и Wayland, адаптация под новое оборудование значительно упрощается, что делает Sailfish привлекательным решением для производителей устройств.

• SailfishOS страдает от нехватки современного оборудования и поддержки, что делает его непрактичным для большинства пользователей.
• Jolla не вернула деньги за неотгруженные планшеты, что вызвало негодование и отказ от поддержки.
• Попытки запустить Sailfish на других устройствах ограничены отсутствием полной поддержки драйверов и невозможностью использовать Android-приложения без Google Play Services.
• Несмотря на то, что Sailfish OS является единственной альтернативой Android и iOS, его развитие и поддержка ограничены ресурсами Jolla.

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

Проект находится на ранней стадии разработки, но уже демонстрирует потенциал для создания более легковесных и безопасных систем. Wasm-модули могут изолированно работать в пространстве ядра, что снижает накладные расходы по сравнению с традиционными процессами. Это особенно ценно для встраиваемых систем, IoT-устройств и сценариев, где критичны безопасность и производительность. Разработчики могут использовать существующие Wasm-инструменты для создания кода, который будет выполняться непосредственно в ядре Linux.

• Проект демонстрирует высокую производительность Linux в WebAssembly, но содержит критические баги (например, ошибки доступа к памяти, паники ядра).
• Потенциальные применения включают облачные терминалы, научные окружения (Jupyter), тестирование дистрибутивов и образовательные цели, но требует оптимизации размера рантайма (<1 МБ).
• Техническое отличие от аналогов (container2wasm, XRSH) — отсутствие эмуляции CPU, компиляция бинарных файлов напрямую в WASM и использование WebWorker для процессов.
• Основные проблемы: отсутствие поддержки сетевых сокетов, сырых сокетов, JIT-компиляции и ограниченная совместимость с инструментами (например, Node.js).
• Участники отмечают образовательную ценность проекта и его влияние на развитие WebAssembly, но скептически оценивают массовое внедрение из-за текущих ограничений.

• Обсуждение в основном вращается вокруг сравнения Windows и Linux: пользователи обсуждают, что Linux предлагает больше свободы, не требует активации и не собирает телеметрии, в то время как Windows требует активации и собирает телеметрии, а также имеет проблемы с безопасностью и стабильностью.
• Также обсуждается, что игры на Linux работают примерно в 90% случаев, но не все игры работают, особенно мультиплеерные игры из-за анти-чит систем.
• Участники обсуждают, что LibreOffice и GIMP не могут полностью заменить Microsoft Office и Photoshop, но они могут быть достаточно для большинства пользователей.
• Также обсуждается, что Windows 10 LTSC может быть установлен без телеметрии и блотвэара, но это не легально и может быть проблематично в будущем.
• В конце, участники приходят к выводу, что выбор между Windows и Linux зависит от индивидуальных потребностей и приоритетов, и что обе системы имеют свои плюсы и минусы.

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

Хороший вкус формируется через использование разных инструментов, отбор подходящих и отказ от неподходящих. Автор подчеркивает, что «никакое время, потраченное на обучение, не пропало зря». Он призывает сомневаться в общепринятых нормах, экспериментировать и ломать вещи. Важно найти баланс: автор не тратит все время на настройку neovim, но регулярно пробует новые технологии (GLSL, Rust, Swift), чтобы расширить кругозор и развить способность отличать посредственность от мастерства.

• Обсуждение свелось к тому, что «taste» и «tinkering» — это не про элитарность, а про любознательность и готовность экспериментировать.
• Участники обменялись историями о том, как раньше они тоже «игрались» с настройками, но со временем пришли к минимализму и перестали это делать.
• Поднялась тема о том, что «taste» в разработке ПО — это не про эстетику, а про умение выбирать правильные инструменты и не тратить время на бессмысленные оптимизации.
• Некоторые участники выразили обеспокоенность тем, что статья не раскрывает, что именно делает «taste» важным и почему он важен.
• В итоге обсуждение сошлось на том, что «taste» — это не врождённое качество, а навык, который развивается с опытом и вовремя отпускает человека от бессмысленных занятий.

Согласно последним данным, почти 90% игр для Windows теперь могут запускаться на Linux, что делает игровую платформу Linux более жизнеспособной, чем когда либо. Этот значительный рост совместимости происходит на фоне прекращения поддержки Windows 10, что создает уникальную возможность для геймеров.

Успех связан с развитием таких технологий, как Proton от Valve и Wine, которые обеспечивают эмуляцию Windows-окружения. Эксперты отмечают, что производительность многих игр на Linux теперь сопоставима с Windows, а в некоторых случаях даже превышает ее. Это особенно актуально в св upcoming прекращения поддержки Windows 10 в октябре 2025 года, что может заставить многих геймеров искать альтернативные платформы.

• Пользователи делятся опытом перехода на Linux для игр: кто-то использует Wine/Proton для запуска старых игр, кто-то отмечает, что большинство игр работает без проблем, а кто-то вспоминает, что единственное, что мешает — это античит-решения, которые не поддерживаются в Linux.
• Обсуждается, что большинство игр работает на Linux, но иногда требуется настройка. Пользователи отмечают, что Proton и Wine значительно улучшились, и что большинство игр можно запустить без проблем.
• Участники обсуждают, что Windows становится всё менее привлекательной для геймеров, особенно в контексте Windows 11. Они также отмечают, что Linux становится всё более привлекательной альтернативой.
• Некоторые пользователи делятся опытом, что они полностью перешли на Linux и не жалеют об этом. Они также отмечают, что единственное, что мешает им полностью перейти на Linux, это игры, которые не работают из-за античит-систем, таких как Easy Anti-Cheat и BattleEye.
• Участники также обсуждают, что они не видят причин, кроме как игры, которые не работают из-за античит-систем, чтобы не использовать Linux.

Проект vivier/phomemo-tools представляет собой CUPS драйвер для принтера этикеток Phomemo M02, позволяющий интегрировать это устройство в Unix-подобные операционные системы. CUPS (Common Unix Printing System) - стандартная система печати для Linux и macOS, и этот драйвер расширяет её возможности, добавляя поддержку доступного портативного принтера этикеток. Это решение особенно ценно для автоматизации печати наклеек в домашних или небольших офисных условиях, где требуется маркировка товаров, файлов или других предметов.

Драйвер поддерживает печать через USB-соединение и включает в себя утилиты для управления принтером из командной строки. Проект с открытым исходным кодом позволяет пользователям вносить изменения и адаптировать функционал под свои нужды. Для установки драйвера требуется наличие Python и нескольких зависимостей, что делает его доступным для большинства современных Linux-систем. Это решение значительно упрощает использование бюджетного принтера в профессиональной среде без необходимости поиска проприетарного программного обеспечения.

Agh, I got myself a Niimbot D110 because it seemed to be the best supported "cheap" label printer (using the excellent https://niim.blue/ website).If I knew these printers had CUPS drivers I might have gone that way instead.. Is there a device you can recommend for printing (stic

Linux-ядро может запускаться как обычный процесс в пространстве пользователя без использования традиционного ПО для виртуализации. Эта технология, известная как User Mode Linux (UML), позволяет создавать виртуальные машины без QEMU или прав суперпользователя. UML можно рассматривать как паравиртуализированную конфигурацию ядра, которая использует существующее ядро хоста и его функции пространства пользователя. Вместо прямого доступа к физическому оборудованию, UML использует файлы и сокеты для создания нового экземпляра ядра, способного запускать собственные процессы. Интересно, что драйверы в UML "просветлены" - они осведомлены о работе с виртуализированным оборудованием и могут оптимизировать взаимодействие.

Для сборки UML-ядра требуется платформа x86, где оно может работать поверх существующего x86-ядра. Процесс сборки начинается с команды ARCH=um make menuconfig, где можно настроить специальные опции UML. Важно включить опцию BLK_DEV_UBD, которая позволяет обращаться к файлам хоста как к блочным устройствам. После финализации конфигурации ядро собирается командой ARCH=um make -j16, создавая бинарный файл linux. Интересно, что этот файл является динамически связанным исполняемым файлом с библиотекой C, а не традиционным ядром, работающим напрямую с железом.

• Использ /dev/urandom вместо /dev/zero при инициализации образа диска вызывает вопросы, так как неясно, какой практический смысл в этом есть при отсутствии шифрования.
• UML (User-mode Linux) позволяет запускать ядро как обычный процесс, но ограничен одним CPU и не поддерживает SMP, что ограничивает его практическое применение.
• Появление SKAS (Separate Kernel Address Space) и дальнейшее развитие виртуализации сделали UML менее актуальным, но он всё ещё может быть полезен как промежуточное решение между контейнерами и полноценными VM.

Четыре десятилетия назад домашние компьютеры предоставляли пользователям полную свободу — можно было запускать любое ПО, от программ от друзей до самописного кода. Сегодня эта свобода медленно уходит, и большинство даже не заметили, как оказались в "садовой ограде". Google недавно объявил о новых ограничениях на установку APK-файлов в Android, начиная с 2026 года, что сделает невозможным установку приложений вне Play Store без сложных обходных путей. Хотя компания позиционирует это как меру безопасности, это лишь продолжение тенденции, начатой Apple с её полностью закрытой экосистемой iOS.

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

• Пользователи обсуждают, что современные устройства всё меньше позволяют пользователю контролировать собственное оборудование, и это ограничение всё больше распространяется от телефонов к ноутбукам и далее.
• Аргументы о «безопасности» и «пользовательском опыте» используются для оправдания всё более закрытой архитектуры, но критики считают, что это просто способ ограничить свободу пользователя и создаёт монополию.
• Участники обсуждения подчеркивают, что даже если пользователь хочет выбрать свободную альтернативу, такую как Linux, он всё равно сталкивается с аппаратными ограничениями, которые делают невозможным установить альтернативную ОС.
• Поднимается вопрос, что если железо не позволяет установить свободную ОС, то это может быть не столько безопасностью сколько контролем и монополизацией.

Разработчик создал неофициальную реализацию Microsoft Recall для Linux, позволяющую автоматически записывать действия пользователя для последующего поиска. Проект использует Wayland для захвата экрана и работает в средах GNOME и KDE Plasma, сохраняя данные локально в базе SQLite. Интерфейс поиска позволяет находить нужные моменты по текстовому запросу, аналогично оригинальной функции Windows.

Ключевое отличие — полное локальное хранение данных без отправки в облако, что повышает приватность. Реализация использует Python и GTK4, поддерживает фильтрацию по приложениям и временным промежуткам. Проект находится на ранней стадии разработки, но уже демонстрирует основной функционал Recall. Разработчик отмечает, что это экспериментальный проект, не связанный с Microsoft.

• Обсуждение началось с сатиры о Recall, но быстро перешло к обсуждению приватности и контроля.
• Участники обсуждали, что идея локального логирования активности может быть полезной, если она реализована прозрачно и под контролем пользователя.
• Были упомянуты альтернативы вроде openrecall и Dayflow, но также подчеркнута важность того, чтобы любое подобное ПО было открытым исходным кодом и не требовало бы передачи данных на внешние серверы.
• Участники также обсудили, что даже если бы идея была реализована в виде скрипта, который бы делал скриншоты и распознавал их с помощью tesseract, это бы все еще вызывало те же самые вопросы приватности.
• В конце обсуждение вернулось к тому, что даже если бы такой скрипт был бы полезен, он бы все еще требовал бы полного доступа к системе и потенциально мог бы быть использован злоумышленниками.

Процесс загрузки 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 выполняет ELF-бинарные файлы — основной формат программ в современных Linux-системах. Поддержка ELF реализована в файле fs/binfmt_elf.c, где основная функция load_elf_binary() занимает более 400 строк кода — вчетверо больше, чем поддержка старого формата a.out. ELF-файл содержит заголовок ELF и таблицу заголовков программы, из которой ядро извлекает три ключевых типа записей: PT_LOAD (описывающие области памяти программы), PT_INTERP (определяющий компоновщик) и PT_GNU_STACK (указывающий, должен ли стек быть исполняемым).

Процесс загрузки начинается с проверки формата файла и чтения его заголовков. Затем функция вызывает flush_old_exec(), которая очищает состояние ядра, унаследованное от предыдущей программы, убивает другие потоки процесса и очищает обработку сигналов. Это обеспечивает чистый запуск новой программы с одним потоком. Интересно, что BSS-секция (для неинициализированных данных) в ELF-файле хранится только как размер, так как ядро заполняет её нулями при загрузке.

• Пользователи обсуждают, что в детстве изучение формата ELF привело к интересу к Linux и программированию.
• Обсуждается, что обработка исполняемых файлов теперь происходит в пространстве пользователя, что, как предполагается, может уменьшить риск крашей ядра из-за ошибок в формате.
• Участники вспоминают, что когда-то процесс загрузки ELF-файлов назывался "image activation", и что эта терминология исчезла после dot-com краха и появления LLM.
• Несколько человек спорят о том, как именно загружаются статические бинарники: часть считает, что ядро все еще обрабатывает их, другие утверждают, что это не так.

В статье рассматривается создание микро-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 или как образ для облачных провайдеров).

• Инструменты для разработки под C64 в Linux и запуска в Vice обсуждаются как нечто, что требует дополнительных усилий, поскольку большинство руководств ориентированы на Windows.
• Участники вспоминают, что в эпоху 8-битных компьютеров разработчики игр использовали хост-компьютеры для сборки и тестирования, а не целевую систему.
• Пользователи делятся впечатлениями о таких играх, как Blood Money и Xenon 2, которые формировали их вкус к шутерам с магазинами и апгрейдами.
• Ностальгия по Lemmings и ожидание ремейка или духовного наследника.

Steinberg выпустил VST SDK 3.8.0 с важными изменениями, включая переход на открытый исходный код под лицензией MIT. Основные обновления включают поддержку MIDI 2.0 с новыми интерфейсами IMidiLearn2 и IMidiMapping2, которые заменяют предыдущие версии, а также добавление отсутствующего перечисления ControllerNumbers для MIDI 1.0. Появилась предварительная поддержка Wayland в Linux с интерфейсами IWaylandHost и IWaylandFrame.

VSTGUI обновлен до версии 4.15.0 с новым API Task Concurrency для выполнения задач в фоновых потоках, поддержкой пользовательских макетов вида, включая GridLayouter, аналогичный CSS Grid, и скриптингом для UIDescription. Также добавлен новый текстовый редактор и предварительная поддержка Wayland. В SDK исправлены ошибки в cmake, helper classes и VST3PluginTestHost, а документация адаптирована под новую модель лицензирования.

• Steinberg/Yamaha открыли исходники VST3 SDK под GPL-3, что стало возможным благодаря давлению со стороны CLAP и сообщества.
• Это снимает юридические барьеры для распространения VST3-плагинов в свободных программах и делает возможным включение SDK в дистрибутивы Linux.
• Одновременно, Steinberg открыла исходники примеров и утилит, что упрощает разработку плагинов и хостов.
• Несмотря на то, что VST3 всё ещё более сложен в реализации, чем CLAP, сообщество продолжит использовать VST3 из-за его широкой поддержки.
• Сообщество приветствует этот шаг как победу свободного программного обеспечения в аудио-индустрии.

Linux capabilities представляют собой механизм контроля доступа, который разделяет привилегии суперпользователя на отдельные единицы. В системе существует 40 таких возможностей, что позволяет более гибко управлять правами доступа, чем традиционная модель "всё или ничего". Статья демонстрирует, как злоумышленник может использовать setcap cap_setuid+ep /usr/bin/python3 для создания бэкдора, позволяющего обычному пользователю получить права root без установки бита SUID. Это особенно опасно, так как традиционные методы поиска эскалации привилегаций фокусируются на файлах с установленными битами SUID и SGID.

Для обнаружения файлов с capabilities можно использовать команду getcap -r /, а для анализа процессов — проверять /proc/[pid]/status или использовать утилиты capsh и getpcaps. Статья подчеркивает важность поиска таких файлов при проведении расследований и аудитов безопасности. Скрипты вроде LinPEAS также включают проверки capabilities при поиске путей эскалации привилегий. Для удаления capabilities с бинарного файла используется команда setcap -r.

• Linux capabilities не реализуют настоящую модель capability-based security, а лишь предоставляют грубые флаги привилегий.
• Проблема в том, что они слишком грубы и не позволяют выдавать только конкретный порт или другой ресурс, а вместо этого разрешают "всё, что угодно, кроме какого-то".
• Наследование прав при fork/exec в Linux не ограничено, что позволяет любой процесс получить доступ к любым ресурсам, если только он может получить fd откуда-нибудь.
• Это делает невозможным реализовать настоящую capability-модель безопасности, где процесс может только делегировать конкретные доступы вместо всего набора прав.
• Подобные ограничения делают невозможным использование механизма в качестве реальной системы контроля доступа, вместо этого он используется лишь как дополнительный слой поверх традиционной модели.

SourceFS — высокопроизводительная виртуальная файловая система, которая ускоряет сборку Android в 9 раз, снижает вычислительные затраты в 14 раз и уменьшает использование диска в 83 раза. Современные кодовые базы огромны: Linux содержит 40 миллионов строк кода, Android AOSP — 140 миллионов+, а автомобильные системы — до 500 миллионов строк. Медленные сборки и выгрузки кода отнимают часы времени разработчиков и милли долларов на CI-ресурсах.

SourceFS виртуализирует всё, материализуя файлы по требованию, что ускоряет выгрузку кода более чем в 10 раз. Система создает виртуальное представление всей кодовой базы и материализует файлы только при необходимости, экономя сотни гигабайт дискового пространства. Для сборки SourceFS использует легковесные песочницы, записывая все шаги и повторяя их для идентичных операций. В результате сборка ускоряется до 10 раз, а на обычном разработческом компьютере — более чем в 9 раз по сравнению с традиционными методами.

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

В файле rlsw.h представлен упрощённый API SimpleWindow для raylib, созданный для быстрой разработки оконных приложений с минимальным кодом. Основная структура SimpleWindow инкапсулирует параметры окна (ширина, высота, заголовок), а SimpleWindowEvent обрабатывает базовые события (закрытие, перемещение, изменение размера). API содержит всего 12 функций, включая swCreateWindow для инициализации, swBeginDrawing/swEndDrawing для рендеринга, и swPollEvents для обработки ввода.

Ключевое преимущество — лаконичность: весь функционал сводится к нескольким вызовам, что идеально подходит для прототипов и небольших проектов. Поддерживаются все основные платформы (Windows, Linux, macOS), а зависимость сводится к одному заголовочному файлу без необходимости линковки. Разработчики отмечают, что это решение особенно полезно для образовательных целей или когда требуется минимальная сложность без избыточных возможностей полного raylib.

• Raylib теперь компилируется без внешних зависимостей, что делает его идеальным для встраиваемых систем и ретро-харда.
• Сообщество вспомнило, что ПО-рендеринг всегда был возможен, и теперь можно делать 2D/3D игры даже на 20-летнем железе.
• Появился спор о том, насколько полезен этот факт для разработки игр на микроконтроллерах и эмуляторах старого железа.
• Некоторые участники обсуждения отметили, что это также открывает путь к созданию игр для таких систем, как Nintendo 3DS и других портативных устройств.
• Были упомянуты проекты TinyGL и PortableGL как альтернативы, а также отмечено, что OpenGL 1.1-совместимое ПО-рендеринг всегда было возможно, но теперь это стало еще более доступным.

x86-64 Playground — это веб-приложение для экспериментов с ассемблером x86-64, сочетающее онлайн-редактор кода и отладчик в стиле GDB. Пользователи могут писать, компилировать и делаться кодом для популярных ассемблеров, включая GNU As, Fasm и Nasm. Уникальность платформы — возможность пошагового выполнения программ с инспектированием памяти и регистров, а также поддержка перетаскивания и отладки любых статических исполняемых файлов Linux без установки дополнительного ПО.

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

• Инструмент позволяет запускать x86-64 машинный код в браузере без бэкенда, используя модифицированный эмулятор blink.
• Проект ориентирован на обучение: интерфейс напоминает GDB, но не реализует продвинутые функции отладчика.
• Пользователи отметили проблемы с инструкцией lzcnt, отсутствие гайдов и неработающие ссылки «Share» и «Guides».
• Появились вопросы о поддержке других архитектур, включая 6502, Game Boy и ARM, а также о возможности GPU PTX.
• Сообщество отметило, что проект полезен как интерактивный учебный ресурс, но не заменяет полноценный отладчик.

Judo — полнофункциональный графический интерфейс для системы контроля версий JJ VCS (также работает с Git-репозиториями). Приложение предлагает визуальные инструменты для управления коммитами, включая журнал операций для возврата репозитория в любую точку времени с возможностью отмены и повтора изменений. Пользователи могут просматривать объединенные диффы нескольких коммитов, применять или откатывать части изменений (ханки) для файлов или коммитов, а также использовать кастомные revsets для фильтрации коммитов по описаниям, авторам и другим параметрам.

Особые возможности включают drag-and-drop перебазирование, продвинутые операции вроде дублирования, разделения, отмены, поглощения и сжатия коммитов, а также управление закладками. Приложение доступно для macOS, Windows и Linux (Ubuntu/Debian), что делает его универсальным инструментом для разработчиков, предпочитающих визуальный подход к работе с системой контроля версий.

• Пользователи обсуждают проект, который, похоже, закрытого исходного кода и не предоставляет информации о себе, что вызывает вопросы доверия.
• Несколько человек выразили желание, чтобы проект стал open-source, даже если бы это ограничило бы только чтение кода.
• Пользователи также обсуждают трудности поиска информации о проекте из-за пересечения названий "jujutsu", "judo" и "git", а также упоминают существующие альтернативы вроде jjui и judo.
• Некоторые пользователи упоминают проблемы с запуском на Ubuntu 24.04 и отсутствие AppImage или других универсальных форматов для Linux.
• Также поднят вопрос о том, что проект использует Compose Multiplatform и, следовательно, не может быть собран из исходников.

Опубликована подробная диаграмма стека сети Linux, созданная Hrvoje Horvat из Ericsson Nikola Tesla. Диаграмма охватывает все уровни сетевого стека: виртуализацию и контейнеры, сокеты, TCP/UDP и нижние уровни с GRO, RPS, RFS и GSO, планировщик сети, NetFilter, управление трафиком, драйверы устройств и функции, ускоренные сетевой картой. Каждый раздел содержит советы по оптимизации и статистику.

Диаграмма доступна в формате PDF (5.4 МБ) и является частью книги "Operativni sustavi i računalne mreže - Linux u primjeni". На момент публикации материал получил 515 просмотров и 380 загрузок. Работа распространяется под лицензией Creative Commons Attribution 4.0 International, что позволяет свободно использовать и распространять диаграмму при обязательном указании автора.

• Диаграмма показывает, как пакет проходит через iptables и Netfilter, что вызвало обсуждение о сложности и важности визуализации в Linux.
• Участники обсуждали, что такие диаграммы редко охватывают контейнеры и виртуализацию, и что отсутствие обновлений может сделать их устаревшими.
• Были вопросы о доступности этих диаграм на разных языках и о том, где можно найти больше информации о книге, из которой они были взяты.
• Также обсуждались вопросы о том, как эти диаграммы могут быть использованы в образовательных целях и о том, что делает их такими полезными для понимания сложных систем.
• В конце, обсуждалось, что такие диаграммы могут быть трудны для чтения в формате PDF и что было бы полезно иметь SVG версию.

Недавняя обнаружение бэкдора в XZ Utils в 2024 году поставило под вопрос безопасность цепочек поставок ПО. Статья исследует, могли ли лучшие практики упаковки в Debian предотвратить эту угрозу, предлагая руководство по аудиту пакетов и рекомендации по улучшению. Бэкдор в версиях 5.6.0/5.6.1 кратко попал в основные дистрибутивы Linux, включая Debian и Fedora, но благодаря бдительности Андреса Фрейнда был быстро обнаружен и удален. Он заметил регрессию производительности SSH в полсекунды, что привело к обнаружению вредоносного кода.

Автор, разработчик Debian, задает ключевые вопросы: почему упаковщики дистрибутивов не заметили ничего подозрительного при импорте новой версии XZ, насколько легко аудировать текущую цепочку поставок ПО, и нет ли еще скрытых бэкдоров. Статья фокусируется на аудите импорта ПО в Debian и его распространении среди пользователей, подчеркивая необходимость проверки исходных кодов пакетов, а не только бинарных файлов. Автор представляет пошаговое руководство по загрузке и анализу исходных пакетов Debian и upstream, предлагая методы для выявления потенциальных угроз.

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

На macOS и Linux команда sort упорядочивает строки по-разному даже при одинаковой локали en_US.UTF-8. Например, на macOS python-dev идет перед python3-dev, а на Linux - наоборот. Причина - в файлах LC_COLLATE: на большинство локалей в macOS ссылаются на la_LN.US-ASCII, что представляет собой базовое ASCII-упорядочивание. Даже для нелатинских локалей (китайской, японской, корейской) используется та же ссылка. В то время как на Linux используются более сложные правила сортировки, учитывающие национальные особенности.

Автор обнаружил, что в macOS 122 из 178 локалей используют la_LN.US-ASCII в качестве основы для сортировки. Исследуя исходный код Apple, он нашел, что правила сортировки для la_LN.US-ASCII чрезвычайно просты - это просто базовое ASCII-упорядочивание без учета национальных особенностей. Это объясняет, почему на macOS "python-dev" идет перед "python3-dev", так как дефис (ASCII 0x2D) имеет меньший код, чем цифра 3 (ASCII 0x33).

• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.

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

Сам процесс не столь гламурен, как кажется: сотрудники GOG тратят месяцы на поиски в архивах и телефонные переговоры. Однако результат стоит усилий — это позволяет сохранить игры, которые иначе могли бы быть утрачены. Более того, GOG часто дорабатывает старые игры, исправляя баги и добавляя поддержку современных систем, что делает их доступными для новых поколений игроков.

• GOG Galaxy не поддерживает Linux, что вызывает недовольство среди пользователей, особенно тех, кто предпочитает DRM-free игры и использует Linux.
• Пользователи отмечают, что GOG не предоставляет нативного клиента для Linux, в то время как Steam и Heroic делают это.
• Некоторые пользователи жалуются на отсутствие поддержки Linux со стороны GOG, что делает невозможным для них покупать игры в этом магазине.
• Некоторые пользователи также жалуются на то, что GOG не предлагает версии игр для Linux, даже если эти игры доступны в других магазинах.
• Некоторые пользователи также жалуются на то, что GOG не предлагает никакой информации о совместимости игр с Linux, в то время как другие магазины это делают.

Крупные компании, включая Google и Meta, вкладываются в развитие BPF для Linux, чтобы ускорить обработку сетевых пакетов и улучшить безопасность. Теперь инструментарий GCC тоже получает поддержку BPF, что расширяет возможности компиляторов для этой технологии.

Основное внимание уделяется интеграции BTF (формат типа BPF) и CTF (компактный формат типа C), которые позволяют эффективно работать с типами данных в BPF. Это важно, чтобы обеспечить совместимость и оптимизацию. В GCC добавлены атрибуты btf_decl_tag и btf_type_tag, которые помогают аннотировать код для лучшей проверки и безопасности.

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

• Обсуждение вращается вокруг лицензии LLVM и Apache 2.0, их совместимости с GPL и влияния на свободное ПО.
• Участники спорят о том, что означает «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.
• Обсуждается, что означает «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.
• Участники обсуждают, что такое «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.

В Linux-сообществе появился интригующий вопрос о новом игроке на рынке x86-совместимых процессоров. Известный эксперт Кристиан Лудлофф сообщил, что некая "корпоративная организация, не являющаяся Intel или AMD", активно использует ряд специфических x86-инструкций и регистров — тех, что десятилетиями не использовались в мейнстриме. Это заставляет задуматься, кто же этот новый игрок. Возможно, это китайская компания Zhaoxin, разрабатывающая собственные процессоры, или же что-то более экзотическое, вроде проекта от Google или другого техногиганта.

Особенно интересно, что Лудлофф упомянул о необходимости избегать конфликтов с этим новым игроком — это намекает, что речь идет о серьезном проекте, а не просто об академическом эксперименте. Ведь если бы это была просто исследовательская группа, вряд ли бы они стали беспокоиться о конфликтах инструкций с существующими продуктами. Также примечательно, что запрос пришел через надежные источники (Лудлофф известен в сообществе) и касается именно production-использования, а не эксперимента.

Сам факт, что новая сущность работает с такими низкоуровневыми компонентами, как управление памятью (MSR — модель-специфичные регистры) и расширениями набора инструкций (opcode), говорит о серьезности проекта. Это не просто какое-то приложение; это что-то, что требует глубокой интеграции с оборудованием. Возможно, это новый тип ускорителя для AI или что-то вроде того, что делает Apple со своими M-чипами, но для x86.

В любом случае, это напоминание о том, что x86 — это не только Intel и AMD. Архитектура продолжает развиваться, и новые игроки могут приносить инновации. Возможно, мы на пороге нового витка в "войне процессоров", как это было в 90-х. Только время покажет, но интрига определенно захватывает.

• Патенты и лицензии на x86 архитектуру всё ещё действуют, несмотря на то, что они обсуждаются как устаревшие.
• VIA, AMD и Intel имеют перекрёстные лицензии, что делает невозможным для других компаний легально производить процессоры совместимые с x86.
• Существуют ли другие компании, кроме AMD и Intel, которые могут легально производить x86 процессоры? Возможно, что нет.
• Cyrix и National Semiconductor были приобретены в 1999 году, и их технологии стали частью AMD и VIA соответственно.
• Существуют ли другие компании, которые могут производить x86 процессоры?

Rust продолжает развиваться, и новые языковые функции, такие как проекции полей, инициализация на месте и произвольные типы self, становятся важными для разработки ядра Linux. Эти функции упрощают работу с указателями, позволяют избежать двойной инициализации и делают код более выразительным. Рядом с этими изменениями, Rust for Linux активно работает над стабилизацией существующих функций и разработкой новых, чтобы код ядра был не только безопасным, но и элегантным. Разработчики подчеркивают, что сообщество, включая участников Rust for Linux, играет ключевую роль в определении приоритетов разработки языка.

• Обсуждение охватывает вопросы от безопасного доступа к полям структур до сложных вопросов владения памятью в Rust, а также влияние этих обсуждений на разработку ядра Linux и взаимодействие с другими языками программирования.
• Участники обсуждали, что сложность Rust может быть препятствием для новых разработчиков, но также отметили, что сложность C++ может быть еще более запутанной.
• Обсуждались вопросы о том, как влияет на разработку ядра Linux внедрение Rust, и были высказаны мнения, что это может быть экспериментом, который следует проводить в другом месте.
• Также обсуждались вопросы о том, какие функции Rust могут быть полезны для разработки ядра Linux и какие функции Rust могут быть полезны для разработки ядра Linux.
• В конце обсуждение перешло к вопросу о том, какие функции Rust могут быть полезны для разработки ядра Linux и какие функции Rust могут быть полезны для разработки ядра Linux.

Корпорация Microsoft активно продвигает Windows 11, но эта ОС вызывает опасения из-за встроенных функций слежки. Например, функция «Recall» записывает действия пользователя и хранит данные в облаке. Некоторые настройки по умолчанию, как интеграция OneDrive, сложно отключить. Edge сложно заменить как браузер по умолчанию.

Из-за этих проблем конфиденциальности автор рекомендует переходить на Linux. Дистрибутивы вроде Zorin OS или PopOS предлагают интерфейс, похожий на Windows, и подходят для обычных задач. Ubuntu и Elementary OS — тоже жизнеспособные альтернативы.

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

В целом, Microsoft движется в сторону тотальной слежки, и Linux представляет собой практичную, этичную альтернативу.<｜begin▁of▁sentence｜>

• Обсуждение в основном касается перехода с Windows на Linux, при этом подчеркнута проблема аппаратных требований Windows 11, которые ограничивают выбор пользователя и способствуют корпоративному контролю.
• Участники обсуждения подчеркивают, что Microsoft использует TPM и Secure Boot как инструменты для ограничения выбора пользователя и продвижения корпоративного контроля.
• Также обсуждается, что Linux дистрибутивы предоставляют альтернативу, но при этом возникают проблемы с совместимостью и поддержкой.
• Участники также обсуждают, что Microsoft продолжает использовать свою монополию для ограничения выбора пользователя и продвижения корпоративного контроля.

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

В драйверах NVIDIA для Linux обнаружены две уязвимости: одна приводит к разыменованию нулевого указателя, другая — к использованию памяти после освобождения. Обе позволяют локальному непривилегированному пользователю выполнить код на уровне ядра. Уязвимости были исправлены NVIDIA в октябре 2025 года.

Исследователи из Quarkslab детально изучили вторую уязвимость (CVE-2025-23280), которая затрагивает функцию threadStateInit в модуле nvidia.ko. Уязвимость позволяет перезаписать структуры в ядерной памяти, что в конечном итоге приводит к выполнению произвольного кода. Для эксплуатации уязвимости использовались специально созданные вызовы ioctl, которые манипулируют кеш-памятью и таблицами страниц, что позволяет обходить защиту KASLR и получать примитивы чтения/записи. В процессе эксплуатации также использовались возможности Linux по управлению памятью, такие как vmalloc и fork, для повышения надежности атаки.

• NVIDIA просит отложить публикацию уязвимостей до января 2026 года, что выходит за рамки стандартного 90-дневного цикла раскрытия.
• Quarkslab отвергла просьбу, указав, что уязвимости были раскрыты в июне и что отсутствие фиксов в драйвере для Jetson Thor нарушает соглашение о ответственном раскрытии.
• Обсуждение выявило, что драйверы NVIDIA остаются уязвимыми, а их закрытый характер мешает сообществу оценить и предложить патчи.
• Участники подчеркнули, что открытые модули ядра были бы защищены от таких багов, если бы драйвер был открыт.
• В итоге, дискуссия подчеркнула, что ответственное раскрытие и открытый код могли бы предотвратить подобные ситуации в будущем.

Остановка потоков Linux требует аккуратного подхода, особенно при работе с низкоуровневыми потоками, созданными через pthread_create или std::thread. В отличие от запуска, корректное завершение потоков позволяет выполнить очистку ресурсов — освобождение памяти, блокировок, сброс логов. Идеального универсального решения не существует, но есть несколько подходов.

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

• Проблема заключается в том, что POSIX не предоставляет безопасного механизма для остановки потока, и это приводит к тому, что разработчики вынуждены полагаться на pthread_cancel, который небезопасен и может привести к утечкам ресурсов или повреждению состояния.
• Попытки использовать SIGUSR1 и signalfd для обработки сигналов в пространстве пользователя не решают проблему, потому что большинство библиотек не ожидают, что их вызовы будут прерваны, и это может привести к повреждению состояния.
• Вместо этого, вместо попыток остановить поток, который может быть в любой точке, лучше структурировать код так, чтобы он мог реагировать на сигнал остановки, или использовать модель, где потоки не блокируются на системных вызовах, а вместо этого используют асинхронные вызовы и ожидают на poll/select/epoll/io_uring.
• Некоторые комментаторы отмечают, что в Linux существует io_uring, который позволяет прервать системный вызов, и что это может быть использовано для реализации остановки потока, но это не решает проблему, что не все вызовы могут быть прерваны таким образом.
• В конечном счёте, вместо попыток убить поток, который может быть в любой точке, лучше писать код так, чтобы он был отзывчив к сигналу остановки, и использовать модели, где потоки не блокируются на системных вызовах, а вместо этого используют асинхронные вызовы и ожидают на poll/select/epoll/io_uring.

Intel анонсировала новый графический процессор "Crescent Island", оптимизированный для задач искусственного интеллекта. Эта модель, основанная на архитектуре Xe3P, оснащена 160 ГБ памяти LPDDR5X. Она специализирована на эффективное выполнение задач логического вывода (inference) с акцентом на производительность на ватт, что делает её привлекательной для центров обработки данных.

Ключевой особенностью является оптимизация под большие языковые модели (LLM): объёмная память позволяет хранить и обрабатывать модели непосредственно на устройстве, снижая задержки. Система использует воздушное охлаждение, что снижает общую стоимость владения.

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

Таким образом, "Crescent Island" представляется как ответ Intel на растущий спрос на энергоэффективные и экономичные решения для ИИ, с акцентом на открытое программное обеспечение и стандартизацию.

• Intel анонсировал 160 ГБ видеопамяти и 2,3 Пфлопс fp16, но цена и сроки появления в продаже остаются неизвестными.
• Пока неясно, будет ли карта доступна для покупки в 2026 году, а цена может оказаться на уровне RTX 5090.
• Вопрос остаётся открытым: будет ли поддержка CUDA/ROCm и какие фреймворки будут работать.
• Поддержка ПО остаётся под вопросом, но Intel утверждает, что у них есть OpenVINO и oneAPI.
• Пока неясно, будет ли карта доступна для покупки в 2026 году, а цена может оказаться на уровне RTX 5090.

Проект KDE отмечает 29-й день рождения и запускает ежегодный сбор средств. Цель — собрать €50,000 к концу года. Эти средства позволят KDE оставаться финансово независимым и продолжать развивать свободное программное обеспечение, которое работает даже на старом железе, снижая электронные отходы. Деньги также помогут адаптировать софт под нужды госучреждений и маргинализированных пользователей.

Кроме того, KDE активно продвигает инициативу End of 10, направленную на сокращение электронных отходов. Вместо того чтобы выкидывать старые устройства, пользователи могут продолжать работать на них с KDE. В этом году сбор особенно важен, так как Microsoft прекращает поддержку Windows 10, что может привести к массовому выводу устройств из строя.

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

• KDE Plasma продолжает оставаться одним из лучших DE, но большинство дистрибутивов по-прежнему не предлагают его как вариант по умолчанию, что особенно удивляет новых пользователей, ищущих альтернативу Windows.
• Пользователи отмечают, что KDE остаётся стабильным, настраиваемым и функциональным, а такие приложения как Dolphin и KDE Connect демонстрируют превосходство над GNOME-эквивалентами.
• Несмотря на то, что KDE — это FOSS-проект с ежемесячными пожертвованиями от сообщества, он всё ещё не получает должного признания в релизах большинства дистрибутивов, что вызывает вопросы о том, почему он не становится стандартным выбором.
• Участники обсуждения также подчеркнули, что KDE предоставляет удобный и привычный для пользователей Windows переход на Linux, в то время как большинство других DE не предлагают такой же уровень знакомства и функциональности.
• Некоторые участники выразили обеспокоенность тем, что KDE может не получать достаточного финансирования и поддержки, несмотря на его вклад в развитие Linux-экосистемы.

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

В Linux они передаются через execve как массив строк вида KEY=VALUE. Внутри процесса они хранятся в стеке или куче, а программы используют разные структуры данных для их представления: Bash использует хешмапы, Python — словари, а C — массив environ.

Важно помнить, что изменения в дочернем процессе не влияют на родительский, и не все инструменты наследуют окружение. Например, login задаёт свежее окружение.

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

• Обсуждение охватило широкий спектр тем: от безопасности переменных окружения до передачи секретов, влияния на разные системы и стандарты, и даже до влияния на разработку программного обеспечения.
• Участники обсуждали, что переменные окружения небезопасны для передачи секретов, так как любой процесс может прочитать их.
• Были упомянуты альтернативы, такие как systemd-creds, которые могут быть использованы для передачи секретов безопасно.
• Также обсуждались проблемы с конфигурацией и стандартами, такие как использование переменных окружения для конфигурации вместо файлов конфигурации.
• Участники также обсуждали влияние переменных окружения на разработку программного обеспечения, включая влияние на разработку в Windows и Unix системах.

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

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

Важный момент: Docker изначально создавался для PaaS-платформы, чтобы упрощать развёртывание приложений, а не изолировать их. Потому и акцент на сборку, а не на безопасность. Многие функции, такие как read-only rootfs, делали контейнеры безопаснее, но главное — они решали проблему управления.

Кроме того, Docker популяризировал Go, показав его эффективность для системного программирования. Сегодня Go — один из главных языков, а многие стандартные библиотеки включают TLS, что упрощает разработку.

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

• Контейнеры появились как реакция на неспособность Linux/Unix обеспечить изоляцию и управление зависимостями, а не как решение для разработки и доставки ПО.
• Docker и подобные инструменты стали популярны, потому что они позволяют разработчикам легко запускать и тестировать приложения в изолированной среде, но это не основная причина их создания.
• Контейнеризация стала возможной благодаря тому, что Google и другие компании внедрили cgroups и namespaces в ядро Linux, что позволило создать легковесную альтернативу виртуальным машинам.
• Использование контейнеров для разработки и тестирования приложений стало возможным благодаря тому, что контейнеры предоставляют изоляцию и контроль над зависимостями, что делает их удобными для этих целей.

Проект Gamedev Guide обновил раздел о современных инструментах Linux для разработчиков. Основное внимание уделено оптимизации рабочего процесса: авторы рекомендуют использовать Docker для изоляции окружений, что ускоряет сборку и тестирование. Особо отмечена интеграция с Windows Subsystem for Linux (WSL2) для кросс-платформенной разработки, а также инструменты вроде Ninja для ускоренной компиляции C++ проектов. В статье приводятся примеры настройки CI/CD пайплайнов под Linux, что особенно полезно для крупных команд. Авторы подчеркивают, что современный Linux уже не уступает в инструментах для разработки под Windows, а в чём-то даже превосходит.

• Обсуждение в основном вращается вокруг того, что «современные» инструменты не всегда объективно лучше, а скорее улучшают UX и визуально оформляют вывод, и что важнее уметь пользоваться базовыми утилитами, чем полагаться на специфические инструменты, которые могут не оказаться в других окружениях.
• Участники обсуждают, что важно знать и уметь использовать базовые инструменты, такие как find, grep, sed, awk, vi, ed, less, tail, head, tar, ls, cat, dd, top, ps, kill, df, du, free, uptime, w, who, last, ls, df, mount, umount, fdisk, lsblk, blkid, lsusb, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsomod, lsmod, lsmod, lsomod, lsmod, lsomod, lsmod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, `

Крупные компании и хостинг-провайдеры активно внедряют MPTCP (Multipath TCP) для повышения отказоустойчивости и производительности. Например, Google и Meta используют его для распределения трафика между сотовыми сетями и Wi-Fi.

MPTCP позволяет одному соединению использовать несколько сетевых интерфейсов одновременно — например, 5G и Wi-Fi — повышая надёжность: если один путь недоступен, трафик автоматически переключается на другой.

В отличие от обычного TCP, MPTCP также поддерживает многопоточность на уровне ядра Linux, что ускоряет передачу данных. Однако для работы MPTOS требуется поддержка на обоих концах соединения, что пока ограничивает его применение.

• MPTCP и SCTP обсуждаются как способы объединения нескольких каналов, но оба сталкиваются с проблемами: MPTCP требует специфической поддержки в ядре и приложениях, а SCTP не поддерживается большинством маршрутизаторов и имеет проблемы с NAT.
• Пользователи отмечают, что MPTCP теперь имеет улучшенный API и может быть полезен для агрегации полосы пропускания и отказоустойчивости, но его использование ограничено тем, что он не может обрабатывать мобильность (handover) без сохранения старых адресов.
• SCTP, хоть и был предложен как альтернатива, но его поддержка в ядре Linux и в коммерческих устройствах оставляет желать лучшего, и он не может пройти через большинство NAT устройств.
• Вопрос о том, почему SCTP не стал широко используемым, обсуждается в контексте его сложности в прохождении через NAT и отсутствия поддержки в потребительских устройствах.

Свободное программное обеспечение не победило, несмотря на то, что многие популярные технологии построены на нём. Хотя открытое ПО повсеместно используется в разработке (Linux, Ruby, GitHub), пользователи часто не осознают, что они используют свободное ПО. Это создаёт иллюзию, что открытое ПО "победило", хотя на самом деле проприетарное ПО доминирует в потребительских устройствах.

Например, хотя существуют открытые альтернативы для 3D-печати, игр и даже смартфонов (Librem 5), они остаются нишевыми. В отличие от этого, проприетарные технологии доминируют в потребительской электронике: смартфонах, телевизорах, автомобилях и других устройствах, контролирующих повседневную жизнь.

Это проблема, потому что программное обеспечение "поглощает мир" — всё больше аспектов жизни контролируются кодом. Если этот код проприетарный, пользователи теряют контроль над своими устройствами. Например, модемы для сотовых сетей часто содержат проприетарную прошивку, что затрудняет создание открытых альтернатив (как в случае с Librem 5).

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

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

KDE Connect — это проект, обеспечивающий интеграцию между настольными компьютерами KDE и мобильными устройствами. Позволяет передавать файлы, SMS, уведомления и управлять устройствами через безопасное соединение. Поддерживается на Linux, Windows, Android, iOS и macOS, что делает его универсальным решением для кроссплатформенной интеграции.

Проект включает в себя как C++ приложение для десктопа, так и мобильные приложения. Для разработки доступны исходные коды, а также инструменты для создания плазмоидов и мобильных QML-приложений. Поддерживается выпуск через различные магазины приложений, включая Google Play, Apple App Store, Windows Store и F-Droid.

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

• KDE Connect и его аналоги (GSConnect, GSConnect) обеспечивают бесшовную связь между устройствами, но сталкиваются с проблемами, такими как несовместимость с различными сетевыми конфигурациями и отсутствие официальной поддержки для iOS.
• Пользователи отмечают, что KDE Connect может быть установлен на различных ОС, включая Linux, Windows и Android, но не на iOS.
• Некоторые пользователи сообщают о проблемах с обнаружением устройств в сети, что может быть связано с настройками фаервола или маршрутизатора.
• Обсуждается, что KDE Connect может быть использован для передачи файлов, управления мультимедиа и других функций, но иногда эти функции могут не работать из-за проблем с подключением.
• Пользователи также обсуждают, что KDE Connect может быть использован для обмена буфером обмена между устройствами, но иногда это может не работать из-за проблем с подключением.

Экспериментальный проект 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, что делает его непрактичным для десктопа.

Четыре года назад я с коллегами снял 3-минутный ролик, в котором 12 USB-флешек и ZFS спасают мир. Видео стало культовым: более 100 000 просмотров, демонстрации на выставках, в блогах и докладах. Но качество на YouTube оставляло желать лучшего, а оригинальный файл в 720p исчез вместе с сервером Sun Mediacast. Я перезалил ролик на Vimeo, где теперь доступны обе версии: английская и немецкая.

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

• Пользователи обсуждают, как технологии за последние 15 лет изменились в плане производительности: сервер 2007 года с 4 ядрами и 16 ГБ ОЗУ сегодня выглядит как ноутбук, а 24 ТБ дискового пространства теперь можно получить на одном диске.
• Обсуждается, почему дистрибутивы по-прежнему используют EXT4 вместо ZFS, несмотря на его преимущества в сжатии, контрольных суммах и защите от битрот.
• Участники спора отмечают, что ZFS не может быть включён в ядро Linux из-за лицензионных ограничений, что мешает ему стать стандартной файловой системой.
• Также поднимается вопрос о том, что рост объёма HDD замедлился и не оправдал ожиданий 1980-х годов.

Краткий пересказ:
lavandula — это минималистичный веб-фреймворк на C, который обещает «скорость C и удобство Python». Проект с открытым исходным кодом, лицензия MIT. Сейчас он находится в стадии альфа-тестирования: базовый роутинг, middleware, JSON-ответы и простой шаблонизатор уже работают. Пример «Hello, world» компилируется в 12 КБ статического бинарника, а полноценный REST API сервис — меньше 100 КБ.

Планы: добавить встроенный ORM, WebSocket и SSE, а также CLI-генератор проектов. Поддержка Windows пока нестабильна, но Linux и macOS уже можно использовать. Сообщество приветствует вклад: обсуждение ведётся в Discussions, а примеры кода и бенчмарки публикуются в репозитории.

• Проект получил похвалу за чистоту и современный стиль кода, но также вызвал споры о практичности и безопасности C-фреймворков.
• Участники обсуждали, насколько целесообразно писать веб-приложения на C, и поднимались вопросы о безопасности и удобстве использования.
• Некоторые отметили, что проект может быть полезен для обучения и как отправная точка для других языков или фреймворков.
• Были также упоминания о том, что проект может быть развит с добавлением функций вроде шаблонизатора или поддержки HTTPS.
• Некоторые комментарии подчеркнули важность тестов и обработки ошибок в коде, а также отметили, что проект может быть использован как основа для других языков или фреймворков.

WinBoat — это инструмент, который позволяет запускать Windows-приложения в Linux с полной интеграцией. Он предоставляет удобный графический интерфейс, автоматизирует установку Windows и обеспечивает доступ к файловой системе Linux из Windows. Проект с открытым исходным кодом, распространяется под лицензией MIT.

• WinBoat – это контейнер Docker с Windows внутри, который запускает приложения в изолированном окружении и предоставляет доступ к ним через RDP.
• Проект не требует лицензии Windows, но юридически он не может быть свободно распространяемым, так как включает в себя не-лицензионные компоненты.
• Пользователи отмечают, что проект не предоставляет никакой новой функциональности по сравнению с существующими решениями, такими как Wine или VirtualBox, и что он не решает проблему, которую он заявляет, что решает.
• Некоторые комментаторы выражают обеспокоенность по поводу того, что проект может быть небезопасен в плане безопасности, так как он требует привилегий root для запуска Docker.
• Проект не предоставляет никакой информации о том, что он делает, и не объясняет, как он это делает, что делает его трудным для пользователей понять, что именно он предлагает.

Microsoft требует обязательной учётной записи Microsoft для установки Windows 11 в домашних версиях, исключая локальные варианты. Это продолжение тенденции привязки ОС к облачным сервисам, что усиливает контроль над пользователями и сбор данных. Ранее подобные требования уже вводились для некоторых сборок, но теперь стали стандартом.

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

• Пользователи выражают разочарование в связи с необходимостью привязки учётной записи Microsoft для установки Windows 11, что усложняет процесс и ограничивает контроль над лицензиями.
• Многие рассматривают переход на Linux (Kubuntu, Mint, Gnome) как жизнеспособную альтернативу из-за разочарования в политике Microsoft, отмечая улучшения в пользовательском опыте и отсутствие слежки.
• Обсуждаются обходные пути для установки Windows без учётной записи Microsoft, такие как использование Rufus, Massgravel, европейских образов или скриптов, но отмечается, что эти методы усложняются.
• Высказывается критика в адрес Microsoft за переход от модели продажи ОС к монетизации пользовательских данных, облачных услуг и рекламы через обязательную привязку к аккаунту.
• Пользователи сталкиваются с проблемами переноса лицензий, купленных через учётную запись Microsoft, при обновлении оборудования, что приводит к безвозвратной потере ключей.

Devpush — это опенсорсная альтернатива Vercel, предназначенная для автоматического деплоя приложений на любых языках программирования. В отличие от коммерческих решений, он не ограничивается JavaScript-экосистемой и работает с любым стеком технологий, предоставляя непрерывную доставку из Git-репозитория.

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

• Пользователи обсуждают и сравнивают различные инструменты для развертывания и управления контейнеризированными приложениями на собственном железе, такие как Coolify, Dokploy, CapRover, Cosmos Cloud, Piku и /dev/push.
• Ключевые темы: простота использования и UX (сравнение с Vercel), поддержка различных рантаймов и Docker, безопасность установки (curl | sh), зрелость и стабильность проектов.
• Автор /dev/push объясняет фокус на удобстве и опыте, близком к Vercel, в отличие от более мощных, но сложных container-centric решений, и анонсирует планы по добавлению новых функций.
• Поднимаются вопросы о необходимости глубоких знаний Linux для самохостинга и ответственности, а также о альтернативных подходах (Kubernetes vs более простые решения).
• Упоминаются recent controversies вокруг Vercel как возможный драйвер роста интереса к альтернативам и открытым решениям.

Microsoft активно закрывает лазейки, позволявшие пользователям устанавливать Windows 11 без обязательной привязки к онлайн-аккаунту. Компания последовательно устраняет методы обхода, включая отключение интернета во время установки или использование командной строки, чтобы вынудить пользователей регистрироваться через учётную запись Microsoft. Это усиливает интеграцию с облачными сервисами, такими как OneDrive и Microsoft 365, но ограничивает выбор для тех, кто предпочитает локальные учётные записи из соображений конфиденциальности или автономной работы. Такая политика вызывает критику со стороны пользователей, ценящих контроль над своими данными и настройками системы.

• Пользователи выражают недовольство политикой Microsoft, особенно обязательной привязкой учетной записи Microsoft в Windows 11, воспринимая это как потерю контроля и приватности.
• Многие рассматривают или уже перешли на Linux как альтернативную ОС, отмечая её улучшившийся пользовательский опыт и свободу от навязчивых функций и слежки.
• Обсуждаются технические обходные пути для установки Windows без учётной записи Microsoft, но отмечается, что компания активно их блокирует.
• Высказывается мнение, что такие изменения вредят бренду Windows, отталкивают пользователей и продиктованы коммерческими интересами, а не заботой о пользователе.
• Подчёркивается, что для корпоративного сегмента, где используются доменные учётные записи, эти изменения не столь критичны, в отличие от обычных пользователей.

Разработчик-энтузиаст, изучая исходники Linux, заметил, что старый ноутбук Fujitsu Lifebook S2110 2005 года неправильно обрабатывает нажатие специальных клавиш «Application» и «Player». Он выяснил, что в режиме «Player» клавиши вообще не генерируют события, а в режиме «Application» они работают, но не так, как ожидается. Вместо этого в журнале ядра появляются сообщения об ошибках ACPI. Он подготовил и отправил на рассмотрение патч, который корректно обрабатывает эти клавиши в обоих режимах, и теперь ждет его включения в основную ветвь Linux.

• Участники обсуждали, как начать вклад в ядро Linux: находить задачи по метке «good first issue», писать патч, проходить ревью и попадать в историю коммитов.
• Подчеркивалось, что даже микро-фикс требует тщательной проверки, но именно такие шаги и делают open-source сообщество устойчивым.
• Несколько человек поделились историями о своих первых коммитах в ядро, включая односимвольное исправление макроса, которое потребовало двух недель перепроверок.
• Участники обменялись советами о том, как начать, если ты не знаешь с чего начать: начни с документации, тестов или мелких улучшений.
• Замечено, что даже если патч кажется мелким, он может быть критически важным для конкретного оборудования, и что такие патчи могут быть применены к старому железу.
• Поднята тема о том, что вклад в ядро Linux может быть полезен при приеме на работу, и что такой опыт ценится.

ScribeOCR — это веб-интерфейс для распознавания текста, проверки OCR и создания полностью оцифрованных документов. Проект полностью открыт: исходники на GitHub, лицензия MIT. Поддерживаемые языки включают русский, китайский, японский и корейский. Поддерживаемые форматы: PDF, изображения, архивы ZIP/TAR. Поддерживаемые устройства: сканеры и камеры. Поддерживаемые ОС: Windows, macOS, Linux и веб-версия. Поддерживаемые форматы экспорта: PDF, DOCX, ODT, PPTX и другие. Поддерживаемые форматы экспорта: PDF, DOCX, ODT, PPTX и другие.

I really like the idea, but unfortunately it could not cope with my usecase.I have some lecture slides as image-only PDF (Hungarian language with a sparkle of English and Latin (biology)). I tried the tool on it and I had the following experience:- proofreading with the overlay s

Toybox — это минималистичная реализация стандартных утилит командной строки для Linux и Android, написанная на чистом C. Она создана как компактная и самодостаточная альтернатива BusyBox, с акцентом на простоту, корректность и соответствие стандартам POSIX. Проект включает основные инструменты вроде ls, cp, mv и многие другие, сохраняя при этом малый размер и избегая внешних зависимостей.

Разработка ведётся с упором на читаемость кода и портируемость, что делает Toybox полезной для встраиваемых систем, восстановительных сред и случаев, где важны предсказуемость и минимализм. Она часто используется в проектах типа Android Toybox, демонстрируя свою практическую ценность для современных ОС.

• Toybox — это альтернатива BusyBox с более разрешительной лицензией (0BSD/MIT-0), созданная для решения лицензионных проблем и использования в Android.
• Оба проекта предоставляют набор стандартных UNIX-утилит (ls, cp, mv и др.) в виде одного исполняемого файла, что экономит место на диске.
• Изначальная идея Toybox вызывала споры из-за отказа от copyleft, но была принята как компромисс для включения в ОС.
• Название Toybox, вероятно, отсылает к коллекции игрушек (аналогично BusyBox) и может быть связано с песней Soundgarden.
• Проект ценится за чистый код и пермиссивную лицензию, но пока не достиг полной функциональной parity с BusyBox.

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

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

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

Cobalt — это программа для рисования текстурной и экспрессивной пиксельной графики, работающая на Windows, Linux и Nintendo DS. Она отличается компактностью, скоростью и простотой использования, предлагая все необходимые инструменты для создания выразительных изображений. Поддерживает до восьми пользовательских цветов и максимальный размер изображения около 400×320 пикселей.

Функции включают настраиваемые кисти, случайное рассеивание для текстур, рисование линий и кривых, рандомизацию цветов, слой для эскизов и экспорт в GIF. Полная версия доступна за $5, а демо можно попробовать онлайн или скачать бесплатно. Для помощи предусмотрена электронная почта поддержки и подробная документация, включая печатное руководство.

• Положительные отзывы о концепции, эстетике и использовании современных технологий для воссоздания ретро-опыта, включая сравнения с Flipnote Studio.
• Вопросы и ответы о технических деталях проекта Bedrock (изменения в спецификациях v1 и v2, доступ к демо-версиям).
• Обсуждение функциональности редактора: настраиваемые инструменты, работа со слоями (скетч-слой), ограничение в два слоя как осознанный дизайнерский выбор.
• Дебаты о ценообразовании ($5): аргументы за бесплатную модель с донатами против обоснованности небольшой платы для поддержки разработчика.
• Ностальгия и интерес к платформе Nintendo DS, её потенциалу для творческих проектов и особенностям (например, резистивный сенсорный экран с чувствительностью к давлению).

Новый iPad с моделью iPad17,3 показал впечатляющие результаты в тесте Geekbench 6: 4133 балла в однопоточном режиме и 15437 в многопоточном. Устройство работает на iOS 26.0 и оснащено 9-ядерным процессором ARM с базовой частотой 4.42 ГГц, разделённым на два кластера — 3 и 6 ядер. Объём оперативной памяти составляет 11.2 ГБ.

В тестах выделяются высокая скорость обработки изображений: Object Remover показал 405.6 Мпикс/с в однопоточном и 1.23 Гпикс/с в многопоточном режиме, а Clang достиг 22.9 тыс. строк/с и 114.4 тыс. строк/с соответственно. Эти цифры демонстрируют значительный прирост производительности для мобильных задач, особенно в сфере ИИ и креативных приложений.

• Пользователи обсуждают производительность нового процессора Apple M5, отмечая его превосходство над конкурентами (Intel, AMD, Qualcomm) в мобильном сегменте, особенно в энергоэффективности и одноядерных тестах.
• Высказывается разочарование ограничениями iPadOS, которые не позволяют раскрыть потенциал мощных чипов Apple, и звучат предположения о возможном появлении сенсорного Mac.
• Обсуждается отсутствие аналога Mac mini на ARM64 для Linux и желание видеть более открытые платформы от Apple с поддержкой Linux и общего назначения.
• Поднимается тема игр: пользователи хотели бы видеть более серьёзный подход Apple к геймингу, включая улучшенные инструменты для портирования игр с Windows (по аналогии с Proton).
• Отмечается, что основной прирост производительности M5 по сравнению с M4 (~10-15%) обусловлен новым техпроцессом и архитектурными улучшениями, а не увеличением частоты.

Файловая система Bcachefs полностью удалена из основного ядра Linux, начиная с версии 6.18. Это решение связано с тем, что разработка переместилась во внешний модуль DKMS, что сделало встроенную версию устаревшей и потенциально вызывающей путаницу. Ранее, в релизе 6.17, система уже была помечена как внешне поддерживаемая.

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

• Пользователи выражают разочарование удалением bcachefs из основной ветки ядра Linux из-за конфликта между его разработчиком и сообществом.
• Обсуждаются технические последствия перехода на DKMS-модуль: необходимость настройки для Secure Boot, потенциальные проблемы с будущими обновлениями ядра.
• Участники сравнивают bcachefs с другими файловыми системами (Btrfs, ZFS), отмечая его потенциал, но критикуя текущую производительность и стабильность.
• Основная причина удаления видится не в технических недостатках, а в неспособности сопровождающего соблюдать правила разработки ядра.
• Высказываются надежды на возврат bcachefs в основную ветку в будущем с другим сопровождающим и после достижения большей стабильности.

Google планирует объединить Android и ChromeOS в единую операционную систему к 2026 году, чтобы создать более унифицированную платформу для устройств. Основным драйвером этого слияния является развитие искусственного интеллекта, который требует более тесной интеграции между мобильными и десктопными системами. Это позволит улучшить взаимодействие пользователей с ИИ-функциями на разных типах устройств.

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

• Обеспокоенность ограничением установки "недоверенных" приложений и потерей пользовательского контроля над устройством, что может превратить устройства в инструменты влияния и рекламы.
• Обсуждение технических возможностей обхода ограничений через ADB, F-Droid и виртуализацию, а также потенциальных конфликтов с регуляторами (например, DMA в ЕС).
• Скептицизм относительно успеха Android на планшетах и больших экранах, а также опасения по поводу будущего Chromebookов в образовании.
• Мнения о том, что слияние Android и ChromeOS является логичным шагом, который уже происходит, и что новый OS может быть ориентирован на десктопный опыт.
• Обсуждение потенциальной замены Linux на Fuchsia и использования Android для проникновения на рынок ПК с Windows, чтобы конкурировать с Apple.

Автор использует технологию XDP (Express Data Path) для высокопроизводительной фильтрации сетевых пакетов прямо на уровне сетевого устройства, что позволяет обрабатывать до 26 миллионов запросов в секунду на потребительском оборудовании. XDP работает поверх eBPF — виртуальной машины в ядре Linux, где код компилируется в низкоуровневые инструкции для быстрой проверки пакетов с гарантиями безопасности, например, предотвращения чтения за пределами буфера.

Для идентификации клиентов, особенно скриптовых инструментов вроде curl, применяется TLS-фингерпринтинг по стандарту JA4. Этот метод анализирует параметры TLS-рукопожатия (версии, шифры, расширения), формируя уникальный отпечаток, который можно сопоставить с конкретным ПО. Хотя расчёт хэша SHA256 напрямую в eBPF сложен, сама возможность такой фильтрации на уровне ядра позволяет эффективно блокировать массовые автоматизированные запросы с минимальными затратами ресурсов.

• Обход TLS-отпечатков (JA3/JA4) возможен через случайный подбор шифров в curl или инструменты вроде curl-impersonate
• Многие системы защиты (например, Anubis) сознательно разрешают запросы от curl и Googlebot, чтобы отсеивать только злоумышленников
• Эффективная блокировка требует комбинации методов: отпечатки TLS, IP-адреса, ASN, HTTP-фингерпринтинг и JavaScript-вызовы
• Мотивированные скрейперы используют продвинутые техники: эмуляцию браузера, вращение отпечатков и прокси
• Борьба со скрейпингом — это "гонка вооружений", ведущая к росту затрат для обеих сторон и рискующая навредить открытости интернета

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

Анализ системного вызова open в ядре Linux показывает три точки отказа: do_open (поздний отказ), link_path_walk (средний) и path_init (ранний). Контейнеризация использует эти механизмы, создавая виртуальную файловую систему и пространства имён, чтобы скрыть реальные файлы от процесса. Это надёжнее, чем полагаться на фильтрацию ввода-вывода в приложении.

• Обсуждение методов изоляции и безопасности для AI-агентов, включая контейнеризацию (runc, podman), Landlock и WebAssembly как потенциальные решения.
• Критика предложенного подхода к песочнице как избыточной или неубедительной для экспертов по безопасности, с акцентом на использование существующих проверенных библиотек и методов.
• Уточнение требований к агенту для код-ревью: доступ только к кодовой базе, истории репозитория, диффам, CI/CD логам и системам отслеживания ошибок.
• Обсуждение практических сложностей реализации, таких как неподдерживаемые системные вызовы в gVisor и необходимость баланса между производительностью и безопасностью.
• Скептицизм относительно новизны и точности объяснения автора, с замечаниями, что описанные методы (chroot) не являются полноценной песочницей или контейнеризацией.

Эксперимент реализует передачу IP-трафика между компьютерами через лазерные лучи, используя Linux-туннель (tun0) и микроконтроллеры ATtiny85. Данные передаются через UART-кабели на скорости 2400 бод, где лазер включается/выключается в зависимости от сигнала, а фотоприёмник считывает световой поток. Пинг и SSH-подключение работают крайне медленно из-за низкой скорости передачи.

Для безопасности применялись защитные очки, так как лазеры могут быть опасны для зрения. Исходный код и схемы доступны на GitHub, демонстрируя простоту логики управления лазером через состояния пинов микроконтроллера.

• Обсуждается проект передачи IP-пакетов через лазерную связь в воздушной среде с использованием TUN/UART.
• Участники отмечают существование аналогичных технологий (PPP/SLIP, оптоволокно, коммерческие лазерные линки) и исторические примеры их применения.
• Поднимаются вопросы практической реализации: помехи, модуляция, скорость, надежность связи при плохих погодных условиях.
• Упоминаются любительские и коммерческие аналоги (RONJA, Taara, long-range Wi-Fi) и сложности синхронизации/ошибок в самодельных системах.
• Обсуждаются альтернативные технологии передачи данных (по электричеству, радио) и ироничные сравнения с «неолитическим интернетом».

Автор обнаружил, что современные файловые менеджеры (включая Google Drive, Windows Explorer, Dolphin и другие) не сортируют файлы в строгом алфавитном порядке. Вместо этого они применяют «естественную сортировку»: если в имени встречаются цифры, система сравнивает их числовые значения, а не символы. Из-за этого file-10.txt оказывается перед file-9.txt, поскольку 10 > 9, хотя буква «1» идёт раньше «9».

Проблема проявилась при сортировке фотографий с двух Android-устройств, где в одном названии миллисекунды были отделены подчёркиванием, а в другом — нет. Это привело к неправильной группировке по времени. Только консольная утилита ls и некоторые UNIX-системы сохранили классическую сортировку. Автор с ностальгией отмечает, что компьютеры теперь часто «думают за пользователя», вместо того чтобы чётко выполнять команды.

• Участники обсуждают разницу между алфавитной и естественной (natural) сортировкой, где числа сортируются по их числовому значению, а не посимвольно.
• Многие пользователи ожидают, что "файл10" будет после "файла9", что является распространённым поведением в современных ОС, хотя это и не строго алфавитный порядок.
• Поднимается вопрос корректности labeling: интерфейсы часто называют сортировку "по имени", а не "алфавитной", что технически позволяет использовать любой алгоритм.
• Некоторые пользователи предпочитают лексикографическую сортировку (например, для хэшей или дат) и критикуют отсутствие выбора алгоритма в системах.
• Обсуждаются сложности сортировки с учётом локалей, не-ASCII символов и контекстно-зависимых правил, делающих единый стандарт невозможным.

IBM IntelliStation POWER 185, выпущенный в 2006 году, использовал процессоры PowerPC 970MP, хотя часто ошибочно причислялся к линейке POWER5. Несмотря на то, что более старшая модель 285 уже применяла DDR2 и POWER5+, 185 откатился к DDR1 и отказался от чипов POWER, вероятно, из-за переиспользования наработок System p5 185 (7037-A50). Это позволило создать менее энергоёмкую и более тихую рабочую станцию с полной совместимостью AIX, которая широко использовалась в госучреждениях и инженерных фирмах США и Японии.

Ключевая особенность системы — аппаратная виртуализация через firmware, что отличает её от Power Mac G5 с тем же CPU. Вероятно, поддержка виртуализации в PowerPC 970MP была добавлена именно по требованию IBM для System p5, тогда как Apple её не использовала. Интересно, что 970MP здесь работал в одноядерном режиме — либо через скрытый переключатель, либо через прошивку, чтобы снизить тепловыделение и позволить использовать компактный кулер. Для «двуядерности» IBM предлагала установить второй такой же чип.

• Ностальгические воспоминания о надежности и гибкости UNIX-систем (AIX, HP-UX) и проприетарных рабочих станциях (IBM, SGI, Sun) эпохи до доминирования Linux.
• Основное преимущество перед Windows XP: специализированное ПО для CAD (например, CATIA V4) и инженерных задач, лучшая производительность, поддержка большего объема памяти и повышенная безопасность.
• Обсуждение технических особенностей архитектуры PowerPC и AIX, включая управление памятью, работу с графикой и редкие особенности вроде валидного нулевого адреса памяти.
• Закат эры проприетарных UNIX-рабочих станций к концу 2000-х из-за конкуренции с более дешевыми и массовыми решениями на x86/Linux и Windows.
• Отдельные комментарии о неудобствах администрирования AIX и использовании специфического периферийного оборудования (трекболов).

Genode — это фреймворк для построения высокозащищённых операционных систем на основе компонентов, применяющий принцип минимальных привилегий и изоляцию процессов. Он использует микроядро, capability-based безопасность и sandboxing для управления сложностью, масштабируясь от встраиваемых устройств до динамических вычислительных систем общего назначения. Ключевые особенности включают строгую организацию компонентов, включая драйверы и системные сервисы, что снижает уязвимости и повышает надёжность.

Фреймворк активно развивается: последние версии, такие как 25.08, добавляют новый планировщик ядра для fairness и низкой задержки, обновляют драйверы Linux до ядра 6.12 и расширяют поддержку микроядра seL4. Для разработчиков доступны подробные руководства — «Genode Foundations» и «Genode Applications», — охватывающие архитектуру, инструменты и портирование приложений, а также Sculpt OS как готовое решение с многомониторной графикой и поддержкой современного железа, включая Intel Meteor Lake.

• Обсуждение архитектуры Genode как набора небольших компонентов, включая ядра и драйверы, в духе философии Unix, но с более широким охватом.
• Вопросы о практическом использовании Sculpt OS: наличие предустановок для десктопа, сложность настройки для новичков и минимальные требования к ресурсам (например, работа с GUI в условиях малого объема RAM).
• Уточнение названия проекта (Genode), которое некоторые участники ошибочно прочитали как "Genocide", и его возможной этимологии.
• Упоминания о долголетии проекта, его использовании разработчиками в качестве основной ОС и демонстрациях на мероприятиях вроде FOSDEM.
• Интерес к текущему состоянию и развитию микрокернельной экосистемы, а также к инструментам для разработки, таким как CI-пайплайны.

В ядре Linux начался процесс отказа от устаревшего метода mmap() в структуре file_operations, который используется с 1992 года. Проблема в том, что он даёт драйверам прямой доступ к критическим структурам управления памятью (VMA), что усложняет обработку ошибок и создаёт риски стабильности. Вместо него введён новый метод mmap_prepare(), вызываемый раньше в процессе маппинга и использующий более безопасный дескриптор vm_area_desc.

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

• Обсуждение касается внутренней переработки в ядре Linux, а не удаления системного вызова mmap(), что успокаивает участников.
• Упоминается исторический контекст использования /dev/zero для выделения анонимных страниц памяти и его возможная замена.
• Участники шутливо предлагают создать новые виртуальные устройства, такие как /dev/seven (источник символа ^G) и /dev/yes (бесконечный поток "y\n").
• Подчёркивается консервативность и глубокая интеграция структуры file_operations в API ядра, что делает её изменение значительным событием.
• Обсуждается принцип "We do NOT break userspace" (Мы НЕ ломаем пользовательское пространство) как фундаментальный для разработки ядра Linux.

• Обсуждаются технические особенности и сравнение производительности Pi 500+ с другими моделями, включая наличие слота M.2 и отсутствие кулера.
• Высказываются сомнения в целесообразности формы «ПК в клавиатуре» и проводятся сравнения с более мощными и дешёвыми мини-ПК.
• Часть пользователей положительно оценивает ностальгический дизайн, бесшумность и низкое энергопотребление устройства.
• Критикуются отдельные технические решения, такие как микро-HDMI порты и отсутствие поддержки полного шифрования диска.
• Высказываются пожелания по дальнейшему развитию линейки, включая модульность и создание телефона на Linux.

На RustConf 2025 обсуждалась совместимость Rust и C/C++, где Чендлер Каррут сравнил подходы Rust и экспериментального языка Carbon. Rust предлагает инструменты вроде bindgen и cxx для взаимодействия, но они слабо подходят для сложного legacy-кода C++ (brownfield), где тесные связи и большой API усложняют миграцию. Carbon же задуман как полностью совместимый с C++ язык, позволяющий постепенно переписывать проекты файл за файлом без смены компилятора, с акцентом на аннотации для безопасности памяти.

Каррут считает, что Rust не скоро решит проблему полной интероперабельности с C++, тогда как Carbon предлагает эволюционный путь, аналогичный переходу от JavaScript к TypeScript. Это даёт пространство для Carbon, особенно в крупных legacy-проектах, где полный переход на Rust непрактичен. Вывод: два языка могут сосуществовать, решая разные аспекты миграции к безопасным языкам.

• Обсуждается сложность и подходы к миграции с C/C++ на современные языки (Rust, Kotlin, Swift), включая инструменты для конвертации и постепенного перехода.
• Поднимаются вопросы о важности качественной интероперабельности между языками и недостатках C как языка-«клея» из-за отсутствия современных функций безопасности.
• Высказываются сомнения в универсальности Rust для полного переписывания из-за архитектурных несовпадений с идиоматическим C++.
• Отмечается, что такие проекты, как Carbon, нацелены на крупные кодобазы (вроде Google) и инкрементальный рефакторинг без полного переписывания.
• Упоминается, что принятие Rust в Linux пока ограничено (драйверы, отдельные подсистемы), а будущее Kotlin и Swift вне их экосистем (Android/Apple) остается под вопросом.

Похоже, это сообщение о процессоре Snapdragon X2 Elite от Qualcomm, но доступ к полной информации требует включения JavaScript в браузере. Без активации скриптов содержимое страницы, включая технические характеристики, производительность или особенности чипа, недоступно для просмотра.

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

• Обеспокоенность недостаточной открытостью и документацией для Snapdragon X2, что затрудняет поддержку Linux и разработку драйверов.
• Вопросы о реальной производительности, энергоэффективности и технических деталях (поддержка TSO, пропускная способность памяти, TDP) без предоставления бенчмарков.
• Скептицизм относительно заявлений о многодневной автономности и маркетинговых формулировок ("легендарный скачок").
• Надежды на появление конкурентов Apple Silicon и качественных ARM-ноутбуков с хорошей поддержкой Linux.
• Обсуждение ниши для ARM-чипов и необходимости поддержки со стороны Microsoft и OEM-производителей.

Проект SonyShell позволяет получить SSH-доступ к камерам Sony DSLR через USB-соединение, превращая фотоаппарат в подобие Linux-устройства. Это открывает возможности для автоматизации съёмки, прямого управления настройками и даже запуска пользовательских скриптов прямо на камере.

Инициатива основана на обратной разработке проприетарных протоколов Sony и использует уязвимости в firmware для выполнения произвольного кода. Практический потенциал включает удалённую съёмку, пакетную обработку и интеграцию с другими системами, что особенно ценно для научных и промышленных применений.

• Обсуждение проекта для удаленного управления камерами Sony через CLI с использованием официального SDK
• Сравнение поддержки API у разных производителей (Canon, Fujifilm, Sony, Blackmagic) и критика встроенных функций Wi-Fi
• Дебаты о корректности термина "DSLR" для беззеркальных камер и предложения по переименованию проекта
• Вопросы о безопасности, функциональности (управление съемкой, передача файлов) и потенциале для модификаций
• Упоминание старых методов взлома (OpenMemories, PMCA-RE) и опыта использования Eye-Fi карт

Larian Studios выпустила нативную версию Baldur's Gate 3 для Steam Deck, которая работает без слоя совместимости Proton. Это снижает нагрузку на процессор и потребление памяти, улучшая производительность. Игроки могут проверить установку через настройки Steam, выбрав инструмент совместимости с Linux Runtime.

Сохранения в нативной версии хранятся в папке /home/deck/.local/share/Larian Studios/, а не в compatdata. Steam Cloud автоматически синхронизирует последние сейвы, но старые можно перенести вручную через режим рабочего стола. Larian подчёркивает, что поддержка Linux ограничена только Steam Deck.

• Обсуждается выпуск нативной версии Baldur's Gate 3 для Steam Deck, отмечаются усилия Larian и улучшение производительности (~10% FPS в Act 3) по сравнению с версией на Proton.
• Поднимаются вопросы о термине "нативная" версия: означает ли она Linux-бинарник, оптимизацию под железо Steam Deck или просто правильную конфигурацию, а также о возможности её запуска на других Linux-дистрибутивах.
• Участники делятся личным опытом игры на Steam Deck: одни хвалят работу через Proton, другие сталкивались с проблемами производительности и теперь рады нативному релизу.
• Критикуется позиция Larian о непредоставлении поддержки для платформы Linux в целом, при этом выпуске сборки под конкретное устройство (Steam Deck) на Arch Linux.
• Затрагиваются смежные темы: проблемы с производительностью старого железа, сравнение с другими играми, баги в процессе обновления через Steam на Linux.

Apple Silicon обеспечивает невероятную энергоэффективность: MacBook M1 Pro теряет всего 10% заряда за три недели в режиме сна. В то же время ноутбук Framework 13 на AMD Ryzen 7840HS разряжается на 3–4% в час даже при простое, что сильно разочаровывает при нерегулярном использовании.

Автор ценит миссию Framework — модульность и ремонтопригодность, но отмечает, что проблема с батареей характерна для многих современных устройств, кроме Apple на ARM. Переход на ARM-платформу для Framework кажется сложным решением, поэтому пока выход — держать ноутбук постоянно подключённым к сети.

• Пользователи отмечают проблемы с энергопотреблением в режиме сна (suspend) на Linux-ноутбуках, особенно по сравнению с Apple Silicon Mac, где управление питанием значительно эффективнее.
• Обсуждаются преимущества архитектуры ARM (включая Apple Silicon и Snapdragon) для автономной работы, но подчеркивается, что ключевой фактор — глубокая оптимизация связки hardware/software, а не просто архитектура.
• Некоторые пользователи в качестве решения для Linux предлагают отключать "modern standby" (S0) в пользу традиционного S3-сна или использовать гибернацию, однако отмечают проблемы с её работой при включенном secure boot и lockdown.
• Высказывается мнение, что открытость и ремонтопригодность Framework важнее максимальной автономности, но многие хотели бы видеть от Framework вариант на ARM-процессоре.
• Упоминаются положительные примеры хорошего управления питанием на отдельных устройствах под Linux (например, некоторые ThinkPad) и под Windows на Snapdragon, что указывает на роль OEM-производителей и драйверов.

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

На ядрах Linux версии 4.0+ алгоритмы свопа значительно улучшены, уменьшая риски избыточного вытеснения страниц. Для SSD использование свопа практически эквивалентно по задержкам работе с файловыми страницами, а на HDD оправдано снижение параметра vm.swappiness. Важно отметить, что отключение свопа не предотвращает проблем в условиях нехватки памяти — оно лишь смещает их в другую область, не решая коренную проблему.

• Обсуждение затрагивает практический опыт использования swap: от успешных кейсов с распределенными системами и Raspberry Pi до проблем с производительностью при нехватке памяти.
• Участники спорят о необходимости swap: одни считают его полезным для вытеснения неактивных страниц, другие — вредным, продлевающим период нестабильности системы при нехватке памяти.
• Критикуется работа OOM killer в Linux за непредсказуемость и предлагаются альтернативы (earlyoom, systemd-oomd, ручной вызов через SysRq).
• Поднимается вопрос о проектировании программ: следует ли избегать аллокации большого объема неиспользуемой памяти или полагаться на swap и перезапуски.
• Отмечается разница в поведении ядер Linux: старые активно использовали swap, современные более консервативны, что вызывает споры о настройках размера swap (от 1.5x RAM до полного отказа).

Safari в macOS 26 Tahoe затемняет видео при отображении нативных элементов управления, как это уже происходит в iOS 18. Это изменение, появившееся между iOS 16 и 18, теперь распространилось и на macOS, подтверждая тенденцию сближения двух операционных систем. Эффект исчезает, если убрать курсор или дождаться скрытия контролов.

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

• Пользователи критикуют Apple за постепенное сближение macOS и iOS, выражая опасения по поводу утраты уникальности десктопной ОС.
• Многие участники обсуждают переход на Linux из-за растущего контроля Apple над macOS и снижения качества пользовательского опыта.
• Обсуждается конкретное изменение в Safari (затемнение видео при показе элементов управления) как пример нежелательного заимствования из iOS.
• Высказывается мнение, что критика отдельных изменений как признака слияния ОС преувеличена и нелогична.
• Некоторые пользователи отмечают, что подобные споры возникают ежегодно, но давление сообщества помогает сохранять macOS стабильной.

WeAct Display FS — это компактный USB-дисплей за $2 с диагональю 0,96 дюйма и разрешением 160×80 пикселей. Он подключается к компьютеру или одноплатнику через обратимый USB Type-A порт, что позволяет гибко ориентировать экран. Устройство отображает системную информацию, погоду или пользовательские изображения через специальное ПО.

Программное обеспечение включает WeAct Studio System Monitor, форк проекта Turing Smart Screen на Python, который теоретически работает на Windows, macOS, Linux и Raspberry Pi OS. Для удобства использования в комплекте идут прокладки, предотвращающие короткое замыкание при перевороте USB-разъёма.

• Выражен интерес к USB-дисплеям с e-Ink, открытым интерфейсом и энергонезависимостью изображения, но отмечена высокая цена и дефицит подходящих моделей.
• Подняты серьёзные опасения по безопасности из-за риска подмены устройства клавиатурой для ввода вредоносных команд.
• Обсуждаются альтернативы: перепрошивка существующих устройств (ESP32, LilyGo), использование старых ридеров или более крупных дисплеев (M5Paper, reTerminal).
• Отмечен феномен покупки гаджетов "для проектов", которые затем не реализуются и пылятся.
• Высказано удивление распространением миниатюрных экранов в неожиданных местах как символа "будущего".

Systemd всё чаще становится причиной скрытых ограничений для демонов, вызывая ситуации, когда служба работает при ручном запуске от root, но отказывает в штатном режиме. Это происходит из-за директив вроде ProtectHome= (блокирующей доступ к домашним каталогам) или PrivateTmp= (создающей изолированный /tmp), которые могут приводить к "таинственным" ошибкам вроде "permission denied" или исчезновению файлов в /tmp.

Особенно коварны ограничения на IP-адреса, которые могут неожиданно блокировать DNS-запросы, если демон не использует systemd-resolved. Пока проблему можно решить, удалив ограничения из .service-файла, но в будущем некоторые демоны могут начать требовать эти настройки, что усложнит диагностику.

• Обсуждаются возможности systemd для изоляции и ограничения сервисов через настройки юнитов, что может служить альтернативой контейнеризации.
• Поднимается вопрос сложности отладки и логирования при использовании усиленных настроек безопасности systemd.
• Участники делятся практическим опытом настройки hardening'а для конкретных сервисов (например, Jellyfin) и решения возникающих проблем.
• Высказываются полярные мнения о systemd: от критики за усложнение и нарушение UNIX-принципов до поддержки за гибкость и мощные функции.
• Затрагивается тема культурного феномена хейта вокруг systemd и его сравнение с другими инструментами (Docker, Podman).

Первый выпуск Linux-смартфона FuriPhone FLX1s полностью распродан, что демонстрирует высокий спрос на устройства с открытой операционной системой. Телефон работает на Linux, предлагая пользователям полный контроль над программным обеспечением и данными, что особенно ценится энтузиастами и разработчиками.

Уже открыт предзаказ на вторую партию, что позволяет новым покупателям забронировать устройство. Проект поддерживает сообщество через форум, гайды и открытый код на GitHub, подчёркивая commitment к прозрачности и совместной разработке.

• Пользователи обсуждают технические характеристики и практичность нового Linux-телефона FuriPhone FLX1, включая его размер, вес, качество экрана и производительность процессора.
• Поднимаются вопросы о программном обеспечении: прозрачность описания ОС, использование Debian/Droidian, поддержка Android-приложений и возможность работы с док-станцией.
• Высказываются сомнения относительно целесообразности покупки из-за нишевости устройства, ограниченной документации и потенциальных проблем с доверием к вендору.
• Часть комментаторов выражает поддержку и энтузиазм по поводу появления работающего Linux-телефона, готового бросить вызов доминированию Android/iOS.
• Критикуется негативный тон многих комментариев, характерный для Hacker News, и призывается к более конструктивному обсуждению инновационных продуктов.

Культура разработки смещается от любознательных инженеров-исследователей к прагматичным метрико-ориентированным специалистам. Раньше разработчики создавали инструменты вроде Linux или Git из чистого любопытства, проводя ночи за экспериментами с технологиями без чёткой цели. Такой подход порождал инновации и глубокое понимание ремесла, а процесс обучения был ценен сам по себе, без ожидания монетизации или масштабирования.

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

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

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

Ключевые компоненты включают расширенную подсистему kexec для загрузки образов, фреймворк межъядерного обмена сообщениями через IPI и механизмы инициализации CPU для x86. Реализация сохраняет обратную совместимость и добавляет интерфейс /proc/multikernel для мониторинга. Пока это черновая версия, требующая тестирования и доработки, но открывающая возможности для zero-down обновлений ядра и новых сценариев изоляции workload'ов.

• Обсуждаются технические сложности совместного использования аппаратных ресурсов несколькими ядрами, включая управление состоянием драйверов, DMA и аппаратными синглтонами (PCI, ACPI).
• Проводятся параллели с существующими архитектурами и проектами: exokernel, Barrelfish OS, OpenVMS Galaxy, CoLinux, Kerrighed и LPAR на мейнфреймах IBM.
• Поднимаются вопросы безопасности: потенциальные уязвимости при совместном доступе к памяти через DMA, отсутствие изоляции между доверенными ядрами и ограниченный периметр атаки при компрометации одного ядра.
• Отмечаются потенциальные преимущества: улучшенная изоляция сбоев (устойчивость к паникам ядра), высокая производительность без накладных расходов виртуализации и возможность запуска разнородных ОС (Linux и BSD).
• Упоминается коммерческий контекст: автор работает над этим в рамках стартапа multikernel.io, что вселяет надежду на понимание производственных сложностей.

Google внедряет систему верификации разработчиков Android, которая потребует регистрации личности даже для установки приложений извне магазина. Новые переменные в Android SDK указывают, что система может блокировать установку, если нет активного интернет-соединения для проверки статуса разработчика — например, при попытке установить APK офлайн. Это может создать проблемы для пользователей с ограниченным доступом в сеть или без доступа к ADB-инструментам. Хотя такие случаи редки, для миллиардов пользователей Android даже редкие сценарии могут стать критичными. Детали реализации ещё уточняются, и у сообщества есть год на поиск обходных решений.

• Пользователи выражают обеспокоенность планами Google ограничить установку приложений извне Play Store, что уничтожит открытость Android и его экосистему Open Source.
• Многие рассматривают переход на Apple из-за разочарования в Android: закрытая экосистема Google не предлагает преимуществ Apple, но лишает свободы выбора.
• Обсуждается потенциальная смерть проектов кастомных прошивок, таких как GrapheneOS, и отсутствие достойных альтернатив для обеспечения приватности и контроля над устройством.
• Поднимается вопрос о юридических последствиях: если закрытая экосистема Apple не считается монополией, то и Google может двигаться в том же направлении без юридических рисков.
• В качестве альтернативы рассматриваются телефоны на Linux, хотя признается их отставание в функциональности, но ценится предлагаемая свобода и конфиденциальность.

Перешёл на KDE как основную среду для игрового ПК, чтобы жена могла комфортно пользоваться компьютером. Изначально выбрал её как альтернативу Sway, но теперь считаю KDE лучшей десктопной средой — даже в сравнении с Windows и macOS.

KDE впечатляет своей полнотой функций. Например, сетевой апплет показывает детальную информацию о Wi-Fi: канал, силу сигнала, MAC-адрес роутера, а также позволяет делиться данными через QR-код. Встроенный инструмент для скриншотов удобен — не нужны сторонние приложения.

Есть и полезные мелочи: управление правами Flatpak через системные настройки, проверка SMART-статуса дисков, кнопка для отключения сна системы. Окна приложений можно гибко настраивать через «Правила окон» — например, убрать автофокус Steam при запуске.

KDE ещё и быстрая. На том же железе она отзывчивее Windows 11, а системные настройки открываются мгновенно. По скорости почти не уступает Sway, хотя анимации можно отключить.

Были небольшие проблемы: при первом запуске панель задач оказалась на ТВ вместо основного монитора. Пришлось добавлять её вручную. Но в целом — это первая среда на Linux, которая действительно радует. Спасибо разработчикам KDE.

• Пользователи высоко оценивают KDE за его настраиваемость, стабильность и богатый функционал, включая такие инструменты, как KDE Connect и Dolphin.
• Многие перешли на KDE с других сред, разочаровавшись в ограниченной кастомизации GNOME и нестабильности его расширений.
• Отмечается значительный прогресс в полировке интерфейса и исправлении ошибок, что сделало KDE конкурентоспособным с macOS и Windows.
• Некоторые пользователи критикуют KDE за остающиеся баги, избыток опций настройки и отдельные проблемы с миграцией на Wayland.
• KDE воспринимается как среда, которая уважает пользователя, предлагает инновации и подходит как техническим специалистам, так и менее технически подкованным людям.

Владелец Dell Inspiron 5567 восемь лет сталкивался со случайными перезагрузками вместо перехода в спящий режим S3. Проблема проявлялась во всех ОС — от Windows до Linux — что указывало на ошибку в прошивке, а не в программном обеспечении.

Изучив декомпилированные ACPI-таблицы через acpidump и iasl, он обнаружил проблему в методе _PTS, который координирует подготовку к сну. Вместо стандартного поведения метод SPTS для южного моста принудительно устанавливал регистр AES3 в единицу для S3-сна, что нарушало ожидаемую последовательность и вызывало сброс системы. Исправление через модификацию DSDT или обновление прошивки устранило проблему, подтвердив, что даже давние аппаратные ошибки можно исправить анализом низкоуровневого кода.

• Проблемы с оборудованием часто исправляются программными костылями из-за экономии производителей, особенно после выхода новых моделей.
• Многие пользователи сталкиваются с ошибками ACPI в Linux (сон, перезагрузка, чтение батареи), требующими ручных правок или патчей ядра.
• Производители редко рассматривают качество ПО как конкурентное преимущество, предпочитая закрытый код, хотя проблемы универсальны для чипсетов.
• Сообщество вынуждено самостоятельно документировать и исправлять баги через патчи DSDT/initrd, иногда спустя годы.
• Новые версии ядра Linux постепенно включают исправления под конкретные модели, улучшая совместимость.

Nvidia и Intel объявили о совместной разработке процессоров Intel x86 RTX SOC для ПК с графикой Nvidia, а также о создании пользовательских серверных процессоров x86 от Nvidia. В рамках масштабной сделки Nvidia приобрела акции Intel на сумму $5 млрд.

• Опасения по поводу негативного влияния на конкуренцию: инвестиции Nvidia могут угрожать развитию графического подразделения Intel (Arc), которое сдерживает цены на GPU и важно для Linux-сообщества.
• Стратегический интерес Nvidia: сделка может быть направлена на получение доступа к производственным мощностям Intel (фабрикам) и созданию гибридных решений (CPU + GPU), а не на прямую конкуренцию на рынке видеокарт.
• Политический и экономический контекст: инвестиции могут быть продиктованы желанием правительства США поддержать национального производителя полупроводников и диверсифицировать цепочки поставок.
• Исторические параллели: сравнение со сделкой Microsoft и Apple в 1997 году, которая спасла последнюю, и надежды на аналогичный положительный исход для Intel.
• Влияние на архитектуру и рынок: возможный сдвиг в сторону интеграции графики в SoC (системы на кристалле) и потенциальные риски для x86-64 лицензирования Intel.

Утечка IPv6 в PureVPN

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

Проблемы затрагивают как GUI (v2.10.0), так и CLI (v2.0.1) клиенты на Linux (тестировалось на Ubuntu 24.04.3 LTS). Вот что обнаружено.

1. Утечка IPv6

После переподключения Wi-Fi или возобновления работы из спящего режима клиент PureVPN не восстанавливает защиту IPv6:

• CLI: Клиент автоматически переподключается и сообщает о статусе "подключено", но система получает маршрут IPv6 через Router Advertisements. Egress-трафик идёт вне туннеля.
• GUI: При обнаружении отключения GUI блокирует IPv4, но IPv6 остаётся рабочим до явного переподключения.

Результат: можно использовать IPv6-сайты и почту с реальным IPv6-адресом провайдера, хотя клиент утверждает о защите.

2. Сброс файрвола

При подключении PureVPN сбрасывает конфигурацию iptables пользователя:

• INPUT устанавливается в ACCEPT
• Все правила -A сбрасываются (включая UFW, Docker)
• После отключения изменения не восстанавливаются

Результат: система остаётся более уязвимой после использования VPN, чем до него. Это противоречит ожиданиям пользователя.

Пример:

# Базовая защита
$ sudo iptables -P INPUT DROP
$ sudo iptables -I INPUT -p icmp -j DROP

# После подключения VPN
$ sudo iptables -S | head -3
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
# Правила удалены

Итог

PureVPN:

• Неправильно реализует kill-switch для IPv6
• Оставляет IPv6 открытым после переподключений
• Сбрасывает состояние файрвола и не восстанавливает его
• Применяет политики ACCEPT для работоспособности

Обе проблемы имеют практическое влияние. Заявления о конфиденциальности подрываются, когда реальный IPv6 утекает, а состояние файрвола теряется.

Полные технические отчёты отправлены на security@purevpn.com. Ответа нет. Используйте с осторожностью.

• Автор поста благодарит за обсуждение и согласен с рисками использования проприетарных VPN-клиентов, отмечая полезность сетевых пространств (network namespaces) для изоляции трафика.
• Многие участники критикуют VPN-провайдеров за плохую реализацию поддержки IPv6, выделяя Mullvad как исключение, но и ему предъявляют претензии.
• Несколько комментаторов настоятельно не рекомендуют использовать PureVPN из-за доказанных в суде случаев логирования трафика, вопреки их заявлениям.
• Высказываются серьёзные сомнения в надёжности закрытого исходного кода клиентов и серверов VPN, предлагается использовать решения с открытым кодом и изоляцией трафика (например, через Vopono или Gluetun).
• Участники обсуждают ненадёжность популярных провайдеров (NordVPN, ExpressVPN) из-за агрессивного маркетинга, моделей ценообразования и возможных связей с определёнными юрисдикциями.
• Предлагаются технические решения для предотвращения утечек: отключение IPv6, использование kill-switch и настройка сетевых пространств через systemd-nspawn или другие инструменты.
• Отмечается, что основная функция VPN — подключение к удалённой сети, а конфиденциальность и безопасность являются вторичными и зависят от доверия к провайдеру.

Проект AMDVLK с открытым исходным кодом прекращён.

• AMD прекращает разработку открытого драйвера AMDVLK и переходит к полной поддержке стороннего драйвера RADV для Vulkan на Linux.
• Сообщество воспринимает это решение как позитивное и долгожданное, поскольку RADV уже давно популярнее у пользователей.
• Высказываются мнения, что полный переход на открытый код всего стека драйверов был бы выгоден для производителей железа.
• Поднимается вопрос о будущем Vulkan-драйвера AMD для Windows и возможности использования там RADV.
• Участники обсуждают сложности открытия кода из-за коммерческой тайны и патентов в проприетарных компонентах.
• Обсуждается влияние решения на развитие ROCm и совместимость с открытым стеком.
• Высказываются опасения о возможном негативном влиянии разработчиков AMDVLK на код RADV.

Телефоны на Linux важнее, чем когда-либо

Android всегда был довольно открытой платформой, но в последние месяцы мы наблюдаем стремительную деградацию экосистемы:

1. Закрытие разработки всё большего числа компонентов в AOSP.
2. Samsung, Xiaomi и OnePlus убрали возможность разблокировки загрузчика. Google, вероятно, последует их примеру.
3. Внедрение Play Integrity API, которое поощряют разработчиков. Даже европейский кошелёк для верификации личности требует его использования, вопреки законам ЕС.
4. Обязательная верификация разработчиков на Android. Это затронет 99,9% устройств, и многие разработчики open-source могут просто прекратить создавать приложения для Android. SyncThing уже прекратил разработку из-за проблем с Google Play.

Google больше не конкурирует с Apple — он перенимает её методы. Android, каким мы его знаем, мёртв или скоро умрёт. Нам нужна открытая альтернатива.

Примечание: это не призыв переходить на Linux сегодня, а указание на необходимость ускорения разработки.

---

Комментарии

y0kai: Мой следующий телефон будет работать на Linux, даже если это неудобно. Как только этот телефон будет оплачен, я также уйду от Google Fi.

MasterOKhan: Я с тобой, я перевёл все свои компьютеры на Linux по похожим причинам. Недавно купил Android-телефон и установил на него Linux, хотя ещё есть над чем работать, например, со звуком и микрофоном. Жду не дождусь, когда смогу отказаться от iPhone.

• Пользователи выражают недовольство ограничениями Android, такими как блокировка скриншотов и записи звонков, несмотря на их законность в некоторых юрисдикциях.
• Обсуждаются возможные альтернативы: использование двух телефонов (один — для банковских приложений, другой — с открытой ОС) или переход на Linux-смартфоны.
• Отмечаются проблемы Linux-телефонов: короткое время работы от батареи, отсутствие поддержки популярных приложений (банки, мессенджеры) и сырой пользовательский опыт.
• Предлагаются решения: форк AOSP, создание устройств без модема (по аналогии с iPod Touch) или использование внешнего модема для разделения trusted/untrusted частей.
• Поднимается вопрос о необходимости открытой мобильной ОС из-за растущей зависимости от проприетарных платформ (Google/Apple) для доступа к госуслугам, банкингу и другим сервисам.
• Высказывается мнение, что усилия сообщества стоит направить на развитие реальных альтернатив (например, PostmarketOS), а не на кастомные прошивки Android.
• Отмечается, что ключевая проблема — не ОС, а экосистема приложений, которые зачастую требуют наличие Google Play Services и блокируются на нестандартных устройствах.
• Некоторые пользователи считают, что регулирование на уровне ЕС (например, форк Android) могло бы улучшить ситуацию с открытостью и безопасностью.

macOS Tahoe

Свежий вид.

Вечно Mac.

macOS Tahoe представляет новый дизайн Liquid Glass — красивый, приятный и мгновенно узнаваемый.

Основные возможности

• Liquid Glass — новый дизайн с прозрачными элементами и динамическими эффектами.
• Приложение "Телефон" — теперь на Mac с поддержкой Live Activities для улучшенной интеграции с iPhone.
• Spotlight — выполняйте сотни действий, не отрывая рук от клавиатуры.
• Умные сокращения — создавайте мощные сценарии с помощью Apple Intelligence.

Дизайн

macOS Tahoe переосмыслен с помощью Liquid Glass, сочетающего свежесть и узнаваемость. Приложения фокусируются на контенте, а персонализация Mac выходит на новый уровень.

• Новый дизайн — Liquid Glass отражает контент в реальном времени, добавляя ясности навигации и элементам управления.
• Обновлённые иконки — персонализируйте Mac с новыми вариантами оформления, включая светлые и тёмные темы, цветные иконки или прозрачный стиль.
• Персонализированные элементы — прозрачная строка меню и расширенные возможности настройки Control Center, включая сторонние приложения.

• Пользователи крайне негативно оценили новый дизайн Liquid Glass в macOS Tahoe, называя его уродливым, непрофессиональным и похожим на дешёвую Android-тему или игрушку.
• Ключевые претензии к интерфейсу: чрезмерно скруглённые углы окон, избыточные отступы (padding), потеря плотности информации, прозрачность, ухудшающая читаемость, и визуальная несогласованность элементов.
• Многие отмечают большое количество багов, неисправленых с бета-версий, и общее ощущение незавершённости и низкого качества релиза.
• Обновление критикуют за ухудшение юзабилити и производительности (например, лагающий запускатель приложений), а также за игнорирование потребностей людей с ограниченными возможностями.
• Некоторые пользователи впервые решили пропустить мажорное обновление macOS и остаться на предыдущей версии или перейти на Linux (KDE), который хвалят за функциональность и стабильность.
• Есть единичные положительные отзывы о новой стилистике, большей «персонализации» и улучшенной производительности в iOS 26, но они тонут в общей массе критики.
• Пользователи отмечают, что Apple отошла от своих прежних принципов дизайна (доступность, ясность, функциональность) в угоду моде.
• Под сомнение ставится сама целесообразность встраивания генерации AI-изображений в операционную систему как её основная функция.
• Общий совет от опытных пользователей — не обновляться до версии x.1 или x.2, чтобы дождаться исправления ошибок и улучшения стабильности.

Встраивание Rust в ядро Linux продвигается с новым API для безопасной обработки ненадёжных данных из пользовательского пространства. Benno Lossin предложил тип Untrusted<T>, который помечает данные как непроверенные и предотвращает их случайное использование в ядре. Этот тип работает на уровне системы типов без накладных расходов в runtime, что делает его эффективным инструментом для маркировки данных из сетевых соединений, съёмных носителей или пользовательских вводов.

API включает утилиты для работы с распространёнными структурами данных, такими как срезы и векторы, и рекомендует интерфейсы вроде read_from_userspace(buf: &mut [Untrusted<u8>]) для безопасного копирования. Для валидации данных введён трейт Validate, хотя его реализация пока требует доработки. Greg Kroah-Hartman предложил добавить пример использования в драйверах, особенно для уязвимых мест вроде ioctl(), где непроверенные данные исторически вызывали переполнения буфера.

• Обсуждаются преимущества строгих типов (например, Untrusted<T>) для повышения безопасности, особенно при обработке пользовательского ввода в веб-приложениях и ядре ОС.
• Отмечается, что подобные подходы уже эффективно реализованы в Rust (для embedded и системного программирования) и Perl ("tainting"), делая код более надежным.
• Подчеркивается, что в C++ также возможна подобная типобезопасность, но она редко используется на практике из-за сложности и инерции сообщества.
• В контексте ядра ОС отмечается, что "ненадежные" данные не только потенциально вредоносны, но и нестабильны (могут меняться конкурентно, быть недоступными).
• Утверждается, что система владения и проверки заимствований (borrowck) в Rust делает подобные API более эргономичными и безопасными по сравнению с C++.

skiftOS
Включите JavaScript для работы приложения.

• За 6 лет автор SkiftOS написал микроядро, загрузчик, графическую оболочку, UI-фреймворк и даже движок браузера.
• Код на современном C++ (модули, async, co_await) и выглядит очень чисто; вдохновение Rust заметно.
• Система CPU-рендеринг, GPU — в планах; сеть пока только HTTP, без HTTPS.
• Безопасность: приложения не видят всю память и железо, драйверы в userspace, доступ по capability.
• Собрать можно под Linux/macOS (./skift.sh run --release <app>), но полный билд сейчас сломан.
• Автор признаёт: почти не было личной жизни, помощь была лишь с движком браузера.

Raspberry Pi в синтезаторах
Недорогая «малинка» вытесняет дорогие DSP-платы.

Цифровой синт — это компьютер под клавиатурой. Раньше для DSP разрабатывали собственные чипы: дорого и долго. Теперь Korg, Erica и другие ставят готовый Raspberry Pi Compute Module: дёшево, мощно, сердито.

Korg
Wavestate, Modwave, Opsix (и их модульные версии) работают на Pi. Внутри — стандартный CM3, Linux и софт-синт Korg. Обновления прошиваются флешкой: распаковал архив — новый синт готов.

Erica Synths
Полностью открытая платформа Perkons HD и модуль Syntrx II тоже на Pi. Пользователи легко меняют прошивки: от классического аналога до драм-машины.

Zynthian
Open-source «коробочка» превращает любую Pi в мультитимбровый синт с экраном и MIDI. Скачал образ — получил Nord, DX7, Serum и ещё 200 энджинов.

Плюсы

• Цена: $40 вместо $400 за DSP.
• Скорость: готовая железка, нет NRE-затрат.
• Гибкость: обновления, новые движки, DIY.

Минусы

• Зависимость от поставок Pi.
• Нужно охлаждение и стабильное питание.
• Производители прячут Pi: гарантия теряется, если вскроешь.

Вывод
Pi уже внутри половины новых цифровых синтов. Следующий ваш клавиш может быть просто клавиатурой к малинке.

• Raspberry Pi (особенно 3/4/5) уже способны заменить дорогие DSP-чипы: синтез, фильтры и эффекты укладываются в кэш, NEON/FMA даёт по 5-10 операций на сэмпл.
• Готовые экосистемы: Zynthian и Monome — «швейцарские ножи» с экранами, кнопками и качественными DAC; RNBO (Max/MSP) и Cardinal (VCV) позволяют разрабатывать на ПК и одним кликом деплоить на Pi.
• Альтернативы Pi: Daisy Seed/Teensy 4.1 для bare-metal, RP2040 в евро-рамках, M8-tracker на Teensy — всё помещается в карман и звучит.
• iOS/iPad + Bluetooth-MIDI = «гаражная студия» за десятки евро: 1:1 эмуляции железных синтов, универсальные покупки Mac/iPhone, минимум проводов.
• Почему не VST: железный корпус с кнопками/энкодерами даёт живое «трогать-тащить» и работает без ноута на репетиции или концерте; надёжность и быстрый старт важнее «чистого ПО».

Хочу, чтобы мой веб-сервер стоял в углу комнаты

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

Это было в 2000 году — до смартфонов, смс, постоянного интернета. Друг из Австралии писал нам из интернет-кафе. Казалось невероятно волшебным.

Но самое магическое было ощущение, что кто-то посещает сервер на моём столе. Я слышал, как жёсткий диск шумит при обращении — словно шаги перед открытием двери.

---

Теперь я могу снова испытать это!

У художника honor ash сайт работает на Raspberry Pi в углу его дома.

Это важно. Во-первых, чувство «Я сделал это!» ведёт к «Я могу сделать что угодно!». Во-вторых, осознание, что посещения людей — это просто крошечная коробка, как и все остальные сайты.

---

Локальный сервер позволяет играть музыку в пространстве. Например, у Карея Хелма в 2015 году на сайте была «Вечеринка»: при наведении на проекты страница становилась инструментом, а Arduino в студии воспроизводила звуки.

Или солнечные сайты — я представляю фотоэлементы на балконе в Барселоне, когда читаю там статью.

---

Это чувствуется transgressively. Сайты должны быть в облаке, вечными, но нет — он реальный! Я могу пнуть его!

---

Это ощущение не ново. Джулиан Диббелл в книге «Моя крошечная жизнь» (1998) описывает виртуальные миры. Он посещает сервер LambdaMOO — непримечательную коробку с кабелями. Он разочарован, но всё ещё держится за фантазию, что весь мир сжат в этом жёстком диске.

Я понимаю это!

---

Видеть сервер — это как виртуальный эквивалент эффекта обзора. Я хочу чувствовать, что комната населена киберпризраками, когда кто-то читает мой блог! Хочу, чтобы и вы испытали это — это изменит наше восприятие.

• Обсуждение преимуществ использования Cloudflare Tunnels и других сервисов (DuckDNS, boringproxy) для упрощения хостинга домашних серверов без прямого выставления в интернет.
• Решение проблемы динамического IP через скрипты для обновления DNS, DDNS или туннелирование для поддержания uptime.
• Ностальгические воспоминания о работе с BBS и ранними серверами, включая возможность наблюдать за действиями пользователей.
• Использование доступного железа для хостинга: Raspberry Pi, мини-PC, старые ноутбуки или даже Android-телефоны.
• Низкая стоимость и мощность домашнего железа по сравнению с облачными провайдерами (AWS), но отмечается проблема шума и энергопотребления.
• Критика асимметрии домашнего интернета: быстрый downstream при медленном upstream, а также стагнация цен в отдельных регионах.
• Обсуждение высокой нагрузки на CPU от дизайна сайта с интерактивными курсорами посетителей.
• Использование LLM (например, Claude-Code) для ускорения разработки side-проектов.
• Оффтоп: обсуждение креативного использования символов канадского флага для написания слова и грамматическая дискуссия о "who's" vs "whose".

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

PythonBPF – пишем eBPF-программы на чистом Python
(в 2 раза короче)

---

Что это
Библиотека pip install pythonbpf компилирует Python-код в объектные .o-файлы и загружает их в ядро как обычные eBPF-программы. Репо: GitHub.

---

Было
Встраивали C в многострочные строки, теряя линтеры и подсветку:

from bcc import BPF
prog = """
int hello(void *ctx) {
    bpf_trace_printk("Hello\\n");
    return 0;
}
"""
b = BPF(text=prog)
b.attach_kprobe(event="sys_clone", fn_name="hello")

---

Стало
Тот же функционал — на Python:

from pythonbpf import bpf, section, compile
from pythonbpf.maps import HashMap
from pythonbpf.helpers import ktime
from ctypes import *

@bpf
def last() -> HashMap:          # глобальная BPF-мапа
    return HashMap(c_uint64, c_uint64, 1)

@bpf
@section("tracepoint/syscalls/sys_enter_execve")
def hello(_: c_void_p) -> c_int32:
    print("entered")
    return 0

@bpf
@section("tracepoint/syscalls/sys_exit_execve")
def bye(_: c_void_p) -> c_int64:
    print("exited")
    last().update(0, ktime())
    return 0

@bpf
def LICENSE() -> str:           # лицензия ядра
    return "GPL"

compile()                       # → .o и загрузка

---

Как работает

1. ast → дерево
2. llvmlite → LLVM IR
3. llc → BPF-объект
4. libbpf → загрузка в ядро

• Участники обсуждают инструмент для компиляции Python в eBPF байт-код, который был создан как проект на хакатоне и пока считается «игрушечным».
• Подчеркивается, что использование LLVM для трансляции в eBPF — более перспективный подход, чем прямое преобразование Python-байткода.
• Несколько пользователей отмечают отсутствие четких объяснений, что такое eBPF, и предлагают добавить больше документации и примеров.
• Критикуется идея использования LLM (больших языковых моделей) для генерации eBPF-кода из-за строгой проверки и специфики eBPF.
• Упоминаются существующие аналогичные проекты для других языков (Java, Node.js) и инструменты из мира BCC.
• Автор проекта признает, что код находится на ранней стадии и требует значительной доработки.

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).

Гипервизор за 1000 строк

Практическое руководство по созданию минимального RISC-V гипервизора, способного загружать Linux. Продолжение книги «ОС за 1000 строк», но теперь на Rust и с нуля (type-1, bare-metal). Используем только важное: сторонние крейты экономят код.
Репозиторий: github.com/nuta/hypervisor-in-1000-lines
Лицензии: текст — CC BY 4.0, код — MIT.

Содержание:
0. Введение

1. Старт
2. Загрузка
3. Hello World
4. Менеджер памяти
5. Режим гостя
6. Страницы гостя
7. Привет из гостя
8. Сборка ядра Linux
9. Запуск Linux
10. SBI
11. MMIO
12. Прерывания
13. Заключение

• Демо-гипервизор на 1000 строк — интересная техническая игрушка, но без паравиртуальных драйверов и прочей инфраструктуры непригоден для реального использования.
• Чтобы запустить RISC-V гипервизор на x86, нужен QEMU, потому что это эмуляция другой архитектуры.
• Желающим увидеть «тот же объём, но на C» скидывают 500-строчный SimpleVisor и репозиторий kvmsample.
• В дискуссию вмешалась философия: «OS» можно уложить и в 5 строк EFI-кода, если не требовать от неё ничего, кроме «Hello, world».

Vicinae — минималистичный лаунчер для ПК:

• нативный, быстрый, расширяемый
• Rust + Tauri
• плагины на JS/TS
• MIT

• Пользователи в восторге: Vicinae — качественный лончер-аналог Raycast для Linux, лёгкий в установке и работе на i3, Hyprland и др.
• Основной плюс — совместимость с расширениями Raycast, но часть из них пока не работает (например, raindrop.io).
• Разработчик планирует улучшить поддержку расширений, добавить ресайз окна и порт под macOS ARM.
• Проект открыт к контрибуциям, но слияние с другим форком маловероятно из-за разных стеков.

HackberryPiCM5 – карманный Linux-компьютер на базе Raspberry Pi CM5.

• 4" сенсорный TFT 720×720 пикс.
• Клавиатура от Blackberry.
• Ультракомпактный корпус, полноценный Linux.

• Устройство на CM5 с клавиатурой Blackberry вызывает восторг «как в 90-х», но критикуют за отсутствие глубокого сна, микроскопические клавиши и необходимость докупать BT-аудиомодуль.
• Большинство сомневаются в практической пользе: «200+ $ — и положит в ящик», слишком мал 4" экран, нет железного видеодекодера, WiFi-адAPTERA и т.д.
• Альтернативы: Beepy с Sharp Memory LCD, uConsole, лэптоп-консоль Pandora-style на RK3588, SPIRIT-смартфон на том же CM5.
• Кто-то хочет просто отдельную USB-клаву Blackberry или планшет + лёгкий BT-клав, другие мечтают о clamshell с 7" и DP-alt USB-C для очков XR.

OpenWrt — Linux для встраиваемых устройств. Вместо статической прошивки даёт полноценную файловую систему и пакетный менеджер: ставь нужные программы, настраивай как хочешь. Разработчикам — готовая платформа; пользователям — полная свобода.

Поддерживаемые модели: таблица совместимости.

---

Новинки

• OpenWrt One — первый роутер проекта (Wi-Fi 6, PoE, слот mikroBUS, $89). С каждой покупки $10 — на развитие OpenWrt.
• Стабильная ветка 24.10.2 (июнь 2025): релиз-ноуты, прошивки.

---

Быстрый старт

• Установка
• Пакеты
• Форум
• FAQ

---

Участие

• Патчи
• Баги
• Вики

• OpenWRT хвалят за стабильность, простоту и надёжность; многие сразу стирают OEM-прошивку и ставят его.
• Недостатки: архаичное ядро/iptables, сложность обновления, отсутствие централизованного управления сетью, «device-centric» подход.
• Часть пользователей хотела бы «десктопный» дистрибутив (Debian/Alpine) вместо специализированной системы, особенно на x86 с большим RAM/flash.
• OpenWRT One пока мало где продаётся, без LUCI, тираж 900 шт; ждут OpenWRT Two от GL.iNet ≈250 $ в 2025 г.
• Некоторые возвращаются к OEM или OPNsense/pfSense из-за пропускной способности, Broadcom-чипов или необходимости IDS/IPS.

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 никто не делает.

• Увлечение — восстановление данных с кассет QIC-80 90-х гг.
• Драйвер ftape (Linux 2.4) последний раз собирался ~2000 г.; с тех пор приходится держать CentOS 3.5.
• Привод подключается к контроллеру гибкого диска: дёшево, но 500 Кбит/с и куча «магии» портов/IRQ.
• Под DOS/Windows есть проприетарные утилиты, но только ftape даёт «сырой» дамп, независимо от формата ПО, которое писало кассету.

Цель: переписать драйвер под современное ядро без боли.
Инструмент — Claude Code (Claude 3.5 Sonnet) в режиме «актов» (акт = автоматический цикл «предложи-отладь-протестируй»).

Ход работы

1. Запустил claude в каталоге исходников ftape-4.04 (1999 г.).
2. Первый акт: «сделай модуль для ядра 6.10». Claude выдал:
   • заменил cli/sti на spinlock_t;
   • sleep_on → wait_event;
   • register_blkdev → blk_mq;
   • kmalloc → kmalloc_array;
   • добавил MODULE_LICENSE/AUTHOR/DESCRIPTION.
     Собралось с десятком предупреждений.
3. Акт 2: «убери варнинги». Убрал устаревшие ioctl, обернул printk в pr_*, добавил fallthrough;.
4. Акт 3: «проверь на x86_64». Исправил long ↔ int в структурах, выровнял u8/u16 через __packed.
5. Акт 4: «протестируй на железе». Создал QEMU-образ с контроллером FDC, подключил образ кассеты.
   • первый insmod — kernel oops; Claude добавил BUG_ON(!request_region) и проверку IRQ.
   • второй — ftape видит привод, но «unknown format»; Claude вставил распознавание QIC-80 по ID_CRC.
   • третий — успешный дамп 120 Мб за 40 мин.
6. Акт 5: «очисти и оформи». Удалил весь #ifdef LINUX_2_0, добавил README.md, Kconfig, Makefile для in-tree сборки.

Результат

• 2 500 строк C → 1 100; 45 файлов → 12; минус 4 архаичных под-драйвера.
• Собирается как out-of-tree (6.6–6.12) и как in-tree (патч 30 Кб).
• Скорость 470 Кбит/с — предел FDC, но стабильно.
• Поддержаны только QIC-80; QIC-40/3010/3020 выкинуты (никто не просил).

Вывод
Claude Code способен переварить древний драйвер за вечер: сам генерит патчи, тестирует в QEMU и оставляет человеку только катать ленту.

• Claude Code и другие LLM-инструменты превращаются в «силовой множитель» для разработчиков: ускоряют работу в знакомых фреймворках и позволяют быстро осваивать новые.
• Главное — самому понимать, что делаешь: чёткие промты, ключевые слова предметной области и умение сверять результат критически снижают количество багов.
• Примеры успеха: порт драйвера ftape с Linux 2.4 на 6.8, апгрейд Pydantic V1→V2, inline-ASM под Apple, модернизация 15-летнего PHP-кода — всё за часы вместо недель.
• Самые ценные фичи: долгие процессы в терминале, автоматическая проверка своего кода, быстрое написание тестов и бенчмарков «на заказ».
• Безопасность: при работе с sudo-операциями или ядром итерации лучше вести вручную, чтобы LLM не сломала систему.

JavaScript отключён.
Включите его или смените браузер.
Проблема может быть в расширениях — отключите их и обновите страницу.

• В MacBook есть датчик угла крышки; он сериализован к материнке, и после замены требует калибровки у авторизованного сервиса.
• Apple использует его для Desk View (коррекция перспективы камеры), а также, возможно, для настройки звука, яркости и диагностики.
• На базе датчика уже сделали «терамен», «протрактор», гироскопические игры и конкурс «самый тупой регулятор громкости».
• В Linux датчик тоже есть (драйвер intel-hinge), но не всегда работает; данные лежат в /sys/bus/iio/devices/.
• Пользователи жалуются, что датчик ломается, вызывает разрядку в сумке и может быть следом «держи ноутбук неправильно».

• JS отключён. Включите его или смените браузер.
• Расширения, блокирующие трекинг, могут мешать — отключите их и обновите страницу.

• Заголовок на HN неверен: задержка касается всех Android, не только AOSP; security-патчи для 13–15 вышли 2 сентября.
• Google всё чаще прячет код в GMS и свои приложения, превращая AOSP в «заготовку» и снижая пользу для GrapheneOS и прочих форков.
• Пользователи обсуждают разделение Android и Google: считают, что без регулирования Google окончательно убьёт открытую часть экосистемы.
• Альтернативы вроде PostmarketOS и «линуксофонов» пока сыроваты: не хватает VoLTE, камеры, GPU и людей для поддержки.

Неофициальный инструмент обхода требований Windows 11 теперь умеет отключать все AI-функции

Утилита Rufus, известная возможностью устанавливать Windows 11 на «несовместимое» железо, получила обновление. Теперь она может полностью вырезать из системы компоненты ИИ: Recall, Copilot, Click-to-Do и другие. Достаточно поставить галочку «Disable AI features» при создании загрузочной флешки — и после установки они будут заблокированы на уровне реестра и служб.

• Пользователи жалуются на встроенную рекламу, телеметрию и невозможность полностью отключить «блоат» в Windows; даже сторонние «деблоатеры» регулярно ломаются после обновлений.
• Многие предлагают «чистую» редакцию Windows (LTSC/IoT), но она дороже, лицензируется пачками и всё равно не лишена шпионских модулей.
• Часть разработчиков и геймеров переходит на Linux (Fedora KDE, Mint, Ubuntu) + Proton/Wine; железные проблемы остаются, но «парадоксально, работает лучше, чем Windows».
• Сообщество сомневается, что Microsoft выпустит публичную «Optimal»-версию без телеметрии: слишком выгодны данные пользователей и рекламные вставки.
• Пока нет закона, обязывающего поддерживать старые CPU; официальные требования Win-11 можно обойти Rufus, но это временное решение, и пользователи всё чаще рассматривают полный уход в Linux/BSD.

Flint — лёгкий инструмент для управления виртуальными машинами Linux.
Клонируй, настрой и запускай ВМ из CLI без лишних зависимостей.

• Пользователи не поняли, что делает утилита: «управляет» KVM-ВМ, но не ясно — создаёт, запускает, монтирует папки или работает по сети.
• Автор показал компактный бинарь на Go, но код (~26 k строк) написан «вайб-кодингом» без тестов, поэтому многим не доверяют.
• Обсуждали альтернативы: systemd-nspawn, libvirt/virsh, Virt-Manager, Cockpit; последний удобен, но по умолчанию слушает 0.0.0.0 и требует PAM-логин.
• Нашлись советы: Cockpit завернуть в SSH-туннель, libvirt подключаться по SSH, PAM заменить на безопасный модуль.
• Вопросы о Vite-hot-reload в гостевой ОС, снапшотах и расписании остались без ответа.

• CXL — это стандарт расширения памяти по PCIe: позволяет добавлять сотни гигабайт/терабайт ОЗУ вне материнки, сохраняя когерентность кэшей.
• Задержка ~200 нс, в ~100 раз выше обычной ОЗУ, но в ~100 раз ниже NVMe; пропускная способность PCIe 5.0 всё ещё высока.
• Первые «доступные» карты (Gigabyte 512 ГБ) уже продаются, но цена и совместимость пока неясны; требуются CPU и материнка с CXL-поддержкой.
• Linux/Windows видит память без специальных драйверов, но для эффективного использования нужно перепроектировать алгоритмы (NUMA, tiering).
• Основные плюсы: дешёвое расширение старой DDR4, shared-memory кластеры, быстрый обмен GPU↔CXL без копирования в основную ОЗУ.

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

• С 2026 г. Firefox прекращает поддержку 32-битных дистрибутивов Linux (x86).
• Последняя версия с 32-битом — Firefox 144; начиная с 145 сборок не будет.
• Пользователям рекомендуют перейти на 64-бит ОС и 64-бит Firefox.
• Для отсрочки доступен ESR 140: обновления безопасности до сентября 2026 г.

• Mozilla прекращает официальную поддержку 32-битных сборок Firefox для Linux, ссылаясь на <2,6 % пользователей и отказ большинства дистрибутивов от i686.
• ESR-ветка будет получать security-апдейты ещё год, после чего 32-битным пользователям придётся перейти на ESR, собирать самим или остаться с уязвимостями.
• Участники спорят: кто-то считает шаг экономически оправданным, другие упрекают в нарушении принципов open-source и напоминают о живучих старых ноутбуках, киосках на Raspberry Pi и энтузиастах OpenBSD/NetBSD.
• Вопросы о чистке кода, размере выгоды от SIMD-оптимизаций и реальном количестве «молчаливых» 32-битных юзеров остаются без точных ответов.

Как выжать максимум из файлового IO в Linux на Zig + io_uring

Тест

• Железо: Ubuntu 24.04, 6.14, NVMe, 32 ядер, 756 ГБ ОЗУ (не влияет, direct_io).
• Параметры: 512 КБ блок, очередь 64, 16 ГБ файл, один поток.

Результаты

	fio	Zig
write	4.08 ГБ/с	3.80 ГБ/с
read	7.33 ГБ/с	7.00 ГБ/с

Zig на 5–7 % медленнее fio, но близко к пределу SSD.

Ключевые фишки реализации

1. Полл-режим (IOPOLL) + nvme.poll_queues=16 → прерывания не нужны.
2. Два экземпляра io_uring: один с IOPOLL (только read/write), второй – для остального.
3. Зарегистрированные буферы: память выделяется заранее, пользователь получает/возвращает готовые блоки.
4. Выравнивание:
   • чтение – внутренняя «перехватка» невыравненных запросов;
   • запись – пользователь сам выравнивает, иначе лишние read-modify-write.
5. Без слияния IO внутри библиотеки – проще и гибче на уровне приложения.

Код: steelcake/csio

• Пользователи указывают, что 7 ГБ/с при 512 КБ блоках — это всего ~14 000 IOPS (~70 мкс/IO), и требуется лишь 1 предзагрузка для полной полосы.
• Напоминают, что Zig 0.15.1 всё ещё меняет IO-API, поэтому версию нужно явно указывать в посте.
• Рекомендуют проверить/увеличить логический блок NVMe до 4 КБ через nvme-format вместо хардкода ALIGN=512.
• Разница 4,08 ГБ/с (fio) и 3,80 ГБ/с (Zig) объясняется путаницей GiB ↔ GB.
• Для io_uring важно использовать registered fds — дают заметный прирост.
• Интересуются, как будет работать тот же код на FreeBSD AIO.
• Предлагают вместо «овераллокации» брать выровненную память через page-аллокатор.

CVE-2024-50264: кратко о сложнейшей гонке в AF_VSOCK
Уязвимость введена в 2016 г. (ядро 4.8); это race между connect() AF_VSOCK и POSIX-сигналом, приводящий к UAF 80-байтового объекта virtio_vsock_sock. Триггер доступен обычному пользователю без user-ns. Ограничения: объект быстро освобождается, UAF-запись делает kworker, система легко падает. За это баг получил Pwnie 2025 «Best Privilege Escalation».

Управление сигналом без самоубийства процесса
Вместо SIGKILL, который убивает эксплойт, используется «бессмертный» сигнал 33:

sev.sigev_signo = 33;
timer_create(CLOCK_MONOTONIC, &sev, &race_timer);
timer_settime(...);  // точный момент прерывания connect()

Сигнал 33 зарезервирован NPTL, процесс его не видит и не завершается.

kernel-hack-drill: тренажёр для ядерных атак
Проект https://github.com/a13xp0p0v/kernel-hack-drill автоматизирует:

• сборку нужных версий ядра Ubuntu 24.04 (6.11 OEM/HWE) с разными конфигурациями KASLR/KCFI/SLAB_QUARANTINE;
• запуск в KVM с заданным RAM/CPU и ssh-форвардингом;
• однокнопочный запуск PoC и сбор crash-дампов.

Инструмент позволил быстро перебирать стратегии перераспределения kmalloc-96, искать объекты-спрей, тестировать разные техники обхода защит и отлаживать эксплойт без ручной пересборки ядра.

Новый путь эксплуатации
Автор отказался от сложной цепочки @v4bel и @qwerty и применил упрощённую схему:

1. Спрей sendmsg()-controlled объектами размером 96 байт, чтобы перехватить освобождённый virtio_vsock_sock.
2. UAF-запись переписывает поле sk_prot, указывая на поддельную структуру proto в userspace-буфере.
3. При последующем вызове close() ядро переходит по контролируемому указателю и исполняет ROP-цепочку, поднимая shell до root.

kernel-hack-drill сократил время от идеи до рабочего PoC с недель до нескольких часов.

• Участники в восторге от глубокого и единоличного описания use-after-free, но признают, что текст местами труден для чтения из-за «роботизированной» подачи.
• Многие чувствуют себя «бесполезными» на таком низком уровне и восхищаются талантом исследователей уязвимостей.
• Поднимается вопрос о мотивации: исследователи редко чинят баги, потому что это требует других навыков и ломает их инсентивы.
• Обсуждается, поможет ли Rust в ядре Linux: write-after-free технически блокируется, но unsafe-области всё ещё оставляют риски.

Краткое руководство

Цель:
Сервер Ubuntu засыпает при простое и просыпается по запросу любого устройства в сети (SSH, Time Machine и т.д.).

Что нужно:

• Сервер с поддержкой Wake-on-LAN по unicast.
• Постоянно включённый маломощный Linux-компьютер (например, Raspberry Pi).

---

На сервере

1. Включить Wake-on-LAN (unicast):

sudo ethtool -s eno1 wol ug
sudo tee /etc/networkd-dispatcher/configuring.d/wol <<'EOF'
#!/usr/bin/env bash
ethtool -s eno1 wol ug || true
EOF
sudo chmod 755 /etc/networkd-dispatcher/configuring.d/wol

1. Автоматический сон по cron (каждые 10 мин):

cat >/home/ubuntu/auto-sleep.sh <<'EOF'
#!/bin/bash
users=$(who | wc -l)
afp=$(lsof -i:548 | wc -l)
[[ $users -eq 0 && $afp -lt 3 ]] && systemctl suspend
EOF
chmod +x /home/ubuntu/auto-sleep.sh
(crontab -l 2>/dev/null; echo "*/10 * * * * /home/ubuntu/auto-sleep.sh | logger -t autosuspend") | crontab -

1. Отключить IPv6 (ARP не работает с IPv6):

sudo sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX="ipv6.disable=1"/' /etc/default/grub
sudo update-grub && sudo reboot

1. Остановить Netatalk перед сном (по желанию):

sudo tee /etc/systemd/system/netatalk-sleep.service <<'EOF'
[Unit]
Description=Netatalk sleep hook
Before=sleep.target
[Service]
Type=oneshot
ExecStart=-/usr/bin/systemctl stop netatalk
ExecStop=-/usr/bin/systemctl start netatalk
[Install]
WantedBy=sleep.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable netatalk-sleep.service

---

На Raspberry Pi

1. Установить ARP Stand-in
   Отвечает на ARP-запросы за спящий сервер.
   https://github.com/danielpgross/arp_standin

2. Опубликовать mDNS-записи (по желанию):

sudo apt install avahi-daemon
sudo tee /etc/systemd/system/avahi-publish.service <<'EOF'
[Unit]
Description=Publish custom Avahi records
After=network.target avahi-daemon.service
[Service]
ExecStart=/usr/bin/avahi-publish -s homeserver _afpovertcp._tcp 548 -H homeserver.local
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now avahi-publish.service

---

Ограничения:

• Сетевая карта сервера должна поддерживать Wake-on-LAN по unicast.
• Лишние пакеты могут случайно разбудить сервер.

• Автор статьи описал сложную схему «спящий сервер + Raspberry Pi-прокси», чтобы экономить электричество и «прозрачно» будить машину по любому сетевому запросу.
• Комментаторы спорят: стоит ли так заморачиваться, если можно просто посылать WoL-пакет, ставить BIOS-таймер или вообще купить сервер, который без нагрузки жрёт 7-15 Вт.
• Некоторые делятся альтернативами: «умные» розетки, механические таймеры, PiKVM, USB-гаджеты для нажатия кнопки питания, RTC-будильник, подвешенные DNS-прокси.
• Часть участников считает игру свеч: «RPi стоит дороже, чем сэкономишь на электричестве»; другие приводят счётчики: 10 Вт круглый год ≈ 25-65 $ в Европе, а у кого-то сервер жрёт 130-160 Вт.
• Итог: если нужна абсолютная прозрачность и нельзя трогать клиентов — решение полезно; в остальных случаях достаточно WoL, BIOS-таймера или просто маломощного железа.

• YouTube
  О платформе | Пресс-центр | Авторские права | Контакты | Авторам | Реклама | Разработчикам
  Условия | Конфиденциальность | Безопасность | Как работает YouTube | Тест новых функций | NFL Sunday Ticket
  © 2025 Google LLC

• IRC стал «точкой входа» в Linux, программирование и даже в профессии: кто-то научился CAD, кто-то писал скрипты для mIRC, а кто-то защищался от WinNuke.
• Люди знаходили друзей, жён и стипендии; 9/11 многие узнавали первым именно в чатах, а не по ТВ.
• Это была первая глобальная «соцсеть» без рекламы и алгоритмов: decentralized, эфемерные каналы, netsplits и «ghost»-бансеры, которые до сих пор держат связь.
• Сегодня IRC живёт в нишах: Libera.Chat, секретные +s-каналы, IRCCloud и пара приваток, куда новичков не зовут, чтобы «не убить атмосферу».
• Основная жалоба: Discord/Slack тяжёлые и коммерческие, IRCv3 с историей идёт медленно, а «золотой век» ушёл вместе с 56k-модемами и телефонными счетами.

Winboat — запуск Windows-программ в Linux с нативным видом и интеграцией.
Использует Wine + патчи для:

• единого меню «Пуск»;
• перетаскивания файлов между ОС;
• общего буфера обмена;
• тем оформления Linux;
• автоматического монтирования дисков.

Установка:

git clone https://github.com/TibixDev/winboat
cd winboat && ./install

Запуск: winboat <путь_к_exe>.

• Пользователи сомневаются в «бесшовной интеграции» и считают, что маркетинговые обещания не совпадают с предупреждениями о багах.
• Уточняется, что WinBoat — это Docker-контейнер с Windows-VM, который через RDP/RemoteApp выводит окна приложений на Linux-декстоп.
• Нет GPU-ускорения; для игр с анти-читом (Fortnite) и тяжёлых задач это ограничение критично.
• Проект позиционируется как более «пользовательский» аналог WinApps, но требует лицензии Windows и всё ещё на стадии бета.

FreeDroidWarn — приложение для Android, которое отслеживает и оповещает о новых уязвимостях в установленных приложениях.
Использует открытые базы CVE и Google Play, проверяет обновления в фоне и показывает уведомления, если найдена угроза.

Основное:

• Бесплатно, без рекламы, open-source (GPL-3).
• Минимальные разрешения, работает офлайн.
• Поддержка темной темы, экспорт/импорт списка приложений.

Установка:
Скачать APK из Releases или собрать из исходников.

• Google с 2026/27 г. требует от разработчиков Android-приложений передавать личные данные; без этого приложения не будут работать на «сертифицированных» устройствах.
• У пользователей остаются варианты: старые версии Android, альтернативные магазины, рут/ADB, GrapheneOS или Linux-смартфоны, но всё требует компромиссов.
• Банки всё чаще требуют «официальные» ОС, что ограничивает свободу выбора; некоторые предлагают веб-версии или работают с GrapheneOS.
• Обсуждаемая библиотека-уведомление оказалась тривиальной и избыточной; лицензию быстро сменили с GPLv3 на Apache-2.0, чтобы не пугать разработчиков.
• Общий вывод: технические «заплатки» не решают проблему, нужны антимонопольные законы и давление со стороны пользователей и законодателей.

Kazeta – Just Play
ОС, возвращающая консольный гейминг 90-х на современное железо: вставил картридж, нажал Power – и играешь.

---

Чистый гейминг

• Без настроек, обновлений, аккаунтов
• Максимальная производительность
• Полное погружение без отвлекающих факторов

---

Создай – коллекционируй – играй

• Делаем физические картриджи из DRM-free игр (SD-карты и др.)
• Игра без интернета и ограничений
• Коллекция навсегда остаётся playable

---

Спокойствие

Никаких: DRM, онлайна, серверов, обновлений, лаунчеров, подписок, микротранзакций.

---

Управление сохранениями

• Автосохранение прогресса
• Ретро-BIOS для просмотра, удаления, резервного копирования сейвов

---

Поддержка игр

• DRM-free AAA и инди
• GOG, itch.io, Linux, Windows
• Классика через эмуляторы

---

Для всех

Безопасно и просто: детям, родителям, бабушкам – всем, кто хочет «просто играть».

---

Скачать kazeta-2025.08.21-x86_64.iso

• Kazeta — это Linux-дистрибутив, который при включении ищет первый файл KZI на SD-карте и запускает описанную в нём игру, имитируя «вставил картридж — сразу играешь» консоль 90-х.
• Пользователей привлекает физическое владение играми, отсутствие онлайн-аккаунтов, патчей, микротранзакций и «анализа выбора».
• Критика: сайт мало что объясняет; SD-карты быстро изнашиваются, мелки и дороги; одна карта = одна игра — расточительно.
• Предложения: использовать карты как «ключи» к уже установленным играм, делать мультиигровые карты, обернуть SD в корпус размером с гейм-картридж.
• Проект ориентирован на ностальгирующих и на родителей, которым проще контролировать детский доступ к играм.

32-битные системы устарели, но ядро всё ещё их поддерживает из-за старого «железа» и ПО.
Arnd Bergmann: новые продукты уже 20 лет выходят на 64-битных платформах; встраиваемые устройства постепенно переходят с armv7 (32-бит) на armv8 (64-бит).

• Arm: 90 % встраиваемых систем; лишь три старые архитектуры до-armv7 ещё можно купить, но ядро держит десяток выведенных из производства. Поддержку можно выбрасывать «по половинам», когда исчезнут пользователи.
• Другие 32-битные архитектуры (arc, microblaze, nios2, openrisc, rv32, sparc/leon, xtensa) вытесняются RISC-V.
• nommu (armv7-m, m68k, superh, xtensa) никто не выпускает, их держат лишь ради существующих систем.

Для несовместимых 32-битных приложений — запуск 32-битного userspace на 64-битном ядре: экономит память, не требует 32-битного ядра.

Боль разработчиков:

• Высокая память (highmem) усложняет mm-подсистему; нужна, когда физической памяти > ~800 МБ.
• Ядро пока держит 32-битные машины до 16 ГБ, но таких почти нет; 4 ГБ встречаются (Chromebook), 2 ГБ — чаще, но «глупо»: память дороже CPU.

• Участники обеспокоены удалением поддержки nommu/32-бит: это уменьшает свободу, лишает возможности запускать Linux на старом или простом железе и делает ядро похожим на «дорожную карту» Apple/Windows.
• Некоторые предлагают форк «Linux Legacy» или переход на NetBSD/OpenBSD, которые по-прежнему поддерживают старые архитектуры.
• Для встраиваемых устройств без MMU считают более подходящими Zephyr, NuttX или Contiki, а не полноценный Linux.
• Поддержка big-endian почти мертва, но сохранится, пока IBM вкладывается в s390x.
• Старые ядра и LTS-дистрибутивы ещё десятилетие обеспечат безопасность и работу выброшенного железа.

Ключевые моменты интервью со Стивом Баллмером

• 34 года в Microsoft: Баллмер прошёл путь от первого бизнес-менеджера до CEO, начиная с сделки IBM DOS.
• Корпоративный бизнес: сам построил направление, превратив его в опору компании.
• Провалы: открыто говорит о том, как упустили мобильные и поиск.
• «Разработчики, разработчики, разработчики»: рассказал историю легендарного лозунга.
• Отношения с Гейтсом: был год, когда они не разговаривали; объяснил, почему ушёл с поста CEO.
• Акции Microsoft: не продал ни одной — капитал вырос с $20 млрд до $130 млрд за 10 лет после ухода.
• LA Clippers и Intuit Dome: поделился планами и энтузиазмом владельца клуба.

Энергия Баллмера — на максимуме: слушайте, чтобы почувствовать «фирменный» стиль.

• Ключевой упрек Баллмеру — застревание в «окнах» и нежелание отпустить Windows-монополию; Наделла же открыл Linux, open-source и вывел Azure на новый уровень.
• Многие удивились, насколько ранним и важным был вклад Баллмера в Azure, а также напряжённости в его отношениях с Гейтсом.
• Некоторые считают Баллмера недооценённым: он знал, кого держать, спас Xbox и построил сверхприбыльный enterprise-департамент, но промахнулся по мобильным устройствам и планшетам.
• У Наделлы упрекают «санитарный» стиль, потерю культуры и якобы набор «средних» сотрудников, тогда как топ-выпускники уходили к Google и Meta.
• Сторонники Наделлы отвечают: Azure и open-source начали двигать ещё при Баллмере, а Microsoft всё ещё эффективно монетизирует Office 365 и корпоративный стек.

ProcMon-for-Linux — порт утилиты Sysinternals Process Monitor для Linux.
Позволяет в реальном времени наблюдать за системными вызовами (open, read, write, fork, exec и др.) и событиями ядра, фильтровать, сохранять и анализировать трейсы.

Ключевые возможности

• CLI-интерфейс, знакомые фильтры pid, process, operation, path, result.
• Форматы вывода: консоль, XML, CSV, JSON.
• Поддержка x86_64, ARM64; ядро ≥ 4.9.
• Сборка: cmake, libsqlite3-dev, libncurses5-dev, libssl-dev, bcc-dev.

Установка

Ubuntu 20.04+

sudo apt install procmon

Или из исходников:

git clone https://github.com/microsoft/ProcMon-for-Linux
cd ProcMon-for-Linux
mkdir build && cd build
cmake ..
make
sudo make install

Быстрый старт

# отслеживать процесс firefox
sudo procmon -p $(pgrep firefox)

# сохранить лог в JSON
sudo procmon -p 1234 -o trace.json -f json

Лицензия

MIT.

• Пользователи обсуждают ProcMon для Linux: кто-то рад, что не придётся опрашивать /proc, кто-то сомневается в целях проекта и его отличии от htop+strace.
• Интересуются совместимостью вывода с Windows-версией и поддержкой телеметрии, а также жалуются на старый INSTALL.md и ограниченные требования (Ubuntu 18.04).
• Некоторые считают утилиту TUI-обёрткой над strace, другие подчеркивают, что она использует eBPF и может следить за всеми процессами без замедления.
• Поднимаются темы «почему нужны сразу GCC и Clang» и «Microsoft всё больше делает инструменты для Linux».

Ошибка всех споров о sideloading
Популярный аргумент: «Я должен запускать любой код на своём железе». Он верен, но в контексте обсуждения — пустой. Google ограничивает не аппарат, а программное обеспечение, поставляемое с ним. iPhone без iOS — уже не тот продукт, поэтому заставлять Apple менять iOS законодательно — значит подрывать его успех.

Критиковать нужно не ограничения ОС, а невозможность по-настоящему управлять железом. Производители обязаны предоставлять документацию и поддержку, чтобы можно было ставить альтернативные ОС: Android на iPhone, Linux на PS5.

• Смартфоны уже не просто гаджеты, а ключ к банкам, госуслугам и повседневной жизни; без аккаунта Apple/Google всё сложнее.
• Большинство сервисов (банки, Netflix и др.) требуют «доверенную» цепочку ПО и железа, поэтому альтернативные ОС фактически невозможны.
• Участники делятся на два лагеря: «открытое железо для всех» vs «безопасные, закрытые устройства для большинства».
• Поднимаются вопросы права собственности, лицензий, IP-законов и даже того, что в будущем мы будем арендовать, а не покупать устройства.
• Реалистичный выход: требовать от гос- и коммерческих сервисов полноценных веб-версий, чтобы не быть привязанным к конкретной ОС.

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-плат.

Один большой сервер вместо оркестра микросервисов

Современный сервер Azure с двумя AMD EPYC 3-го поколения даёт:

• 128 физических ядер / 256 потоков
• до 8 ТБ ОЗУ, 200 ГБ/с пропускная способность
• 128 линий PCIe 4.0 → 30 NVMe + 100 Гбит/с сеть
• 4 TFLOPS — в 2000 г. хватило бы для первой строчки Top500

Что он умеет

• 800 Гбит/с видео (Netflix)
• 1 млн IOPS в NoSQL, 70 k IOPS в PostgreSQL
• 500 k RPS nginx, компиляция ядра Linux за 20 с, кодирование 4K-видео 75 fps

Сколько стоит

• Аренда:
  – OVH: 128 ядер, 512 ГБ ОЗУ, 50 Гбит/с — $1 318/мес.
  – Hetzner: 32 ядра, 128 ГБ — €140/мес.
  – AWS m6a.metal: 96 ядер, 768 ГБ — $6 055/мес.
• Покупка: ~$40 000 за аналогичную конфигурацию у Dell.

Вывод
Для большинства задач один такой сервер перекрывает потребности всей компании. Распределённые системы нужны редко; чаще достаточно «одного большого сервера» и простого деплоя.

• «Облачный налог» заставляет инженеров выбирать только дорогие облачные решения, хотя за $200/мес. у Hetzner можно взять 48 ядер и 128 ГБ ОЗУ, тогда как AWS даёт лишь 4 vCPU и 16 ГБ.
• Многие участники подтверждают: при стабильной нагрузке гибрид «colo + VPS» или одна большая машина дешевле и проще, чем микросервисы и K8s.
• Ключевые риски: единая точка отказа, необходимость админов и железных рук; зато нет «meta-слоёв» Docker-proxy-nginx и можно выжимать максимум из железа.
• Часть команд тратит годы на «cloud-native» пайплайны и закрывается, не успев выйти на рынок; проще начать с PaaS/Hetzner и переезжать, когда счёт действительно больно.
• Для критичных задач достаточно двух физических серверов (active/backup) и CDN; 99,9 % доступности хватает большинству бизнесов, которым на деле не нужен 100 % uptime.

• YouTube
  О платформе • Пресс-центр • Авторское право • Связаться • Авторам • Реклама • Разработчикам • Условия • Конфиденциальность • Правила и безопасность • Как работает YouTube • Тест новых функций • NFL Sunday Ticket

© 2025 Google LLC

• Google усиливает блокировку установки сторонних APK (ReVanced, F-Droid), что вызывает раздражение и разговоры о переходе на iPhone или «думфоны».
• Участники предлагают радикальные меры: отмену DMCA, антимонопольные разбирательства, законодательное право на перепрошивку и ремонт.
• Многие рассматривают альтернативы — LineageOS, GrapheneOS, HarmonyOS, Linux-телефоны (FLX1, Jolla) или удалённый рабочий стол.
• Сообщество фиксирует тренд «компьютер в кармане превращается в закрытую игровую приставку» и обсуждает, как долго ещё можно пользоваться старыми Galaxy без обновлений.

JavaScript отключён.
Включите его или перейдите на поддерживаемый браузер, чтобы продолжить пользоваться x.com. Список браузеров — в Справке.

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

• Кармак: новая ОС требует «монашеского ордена» инженеров, иначе проект затянет «гравитация» существующих решений.
• Бывшие сотрудники Meta и Oculus: XROS отвлекал основные команды, не имел чёткого бизнес-кейса, а критика внутри компании заканчивалась жалобами в HR.
• Технический консенсус: драйверы и экосистема железа сегодня настолько сложны, что проще адаптировать Linux/RTOS, чем писать ОС с нуля.
• Примеры Google Fuchsia и HarmonyOS показывают, что даже гигантам требуются годы и огромные ресурсы, чтобы просто добиться совместимости.
• Итог: без явного стратегического преимущества и готовности к долгосрочным инвестициям новая ОС — дорогой эксперимент ради эксперимента.

Synology раньше нравился, теперь — нет.
Использую DS920, DS418 и DS1522, но новых больше не куплю.

Почему?

• Искусственное ограничение Samba. На новых моделях встроенный обвязчик жёстко режет число одновременных подключений.
• Жёсткая привязка к своим дискам. С 2025 г. NAS отказываются работать с любыми винчестерами, кроме продаваемых самой Synology. Гарантия у их дисков — 3 года, у WD Black — 5.

Куда дальше?
Собрать TrueNAS-сервер или посмотреть UGREEN, Buffalo и других.

• Пользователи жалуются на устаревшее ПО в новых Synology: старые ядра, EOL-версии PHP, PostgreSQL, Samba и др.
• Критикуют политику «только наши диски» и закрытость системы; многие называют это «выжиманием денег».
• Бывшие фанаты признают: раньше «включил и забыл», теперь — vendor-lock и упадок качества.
• Активно обсуждаются альтернативы: самосбор на TrueNAS/Unraid, UNAS Pro от Ubiquiti, TerraMaster, ASUSTOR, обычный Linux-сервер.
• Общий вывод: Synology теряет лояльность энтузиастов; кто готов потратить время, уходит на DIY-решения.

• Пакеты: libxslt, linux-c7-libxslt, linux-rl9-libxslt (версии <2)
• Суть: проект без мейнтейнера, 3 неисправленные уязвимости
• CVE-2025-7424: путаница типов xmlNode.psvi
• CVE-2025-7425: use-after-free в xmlFreeID
• CVE-2025-????: четвёртая уязвимость (18.06.25) пока не раскрыта
• Статус: патчи от Apple и Google есть, но не применены из-за отсутствия мейнтейнера

• Пользователи обсуждают, что libxslt остаётся единственной C-реализацией XSLT 1.0, на которую завязаны браузеры, GNOME-стек и множество дистрибутивов.
• Google отказалась выплачивать bug-bounty за уязвимости, сообщённые контрибьютору libxslt, а новый мейнтейнер всё ещё проходит бюрократическую проверку в GNOME.
• Появились предложения вывести XSLT из браузеров и заменить его WASM-полифиллом или переложить поддержку на Linux Foundation.
• Участники отмечают, что XSLT 1.0 имеет много реализаций (Saxon, Xalan, MSXML), но именно libxslt используется в Chrome/Blink, что создаёт монокультуру.

Debian 13 «trixie» вышла после двух лет разработки: 14 000 новых пакетов, APT 3.0 по умолчанию и официальная поддержка 64-битного RISC-V.
Версии ПО: GNOME 48, Plasma 6.3, Xfce 4.20, Emacs 30.1, LibreOffice 25.2, ядро 6.12.41 LTS, GCC 14.2, Rust 1.85, Python 3.13, systemd 257.
Поддерживаемые архитектуры: amd64, armhf, arm64, ppc64el, s390x, riscv64. i386 исчез, armel последний релиз.

Обновление из bookworm возможно: конвертируйте sources.list в DEB822 (команда apt modernize-sources появится только в trixie), удалите сторонние пакеты и проверьте, что имена сетевых интерфейсов могут измениться.

Установка: от 64 МБ netboot-ISO до образов Blu-ray; для больших образов рекомендуют BitTorrent или jigdo.

• Некоторые пользователи считают «unstable» (sid) вполне стабильной для ежедневной работы, другие подчеркивают, что всё же бывают серьёзные сбои.
• Многие узнали о новом инструменте extrepo для подключения внешних репозиториев, но на Trixie пока встречаются проблемы с зависимостями.
• Trixie хвалят за «дружелюбие» к пользователю и свежие пакеты, однако NVIDIA-драйверы и CUDA-репы пока не обновлены, что вызывает головную боль.
• Для более новых версий ПО советуют backports, Flatpak или официальные deb-пакеты Mozilla, чтобы не ждать ESR.
• Серверные админы считают Debian лучшим выбором для продакшена, но на десктопе ему иногда не хватает свежести.

• Phison не смог воспроизвести проблему, а Microsoft молчит и не публикует детали.
• Нет ясной технической картины: анекдоты множатся, но SMART-данных и логов нет.
• Неясно, «убивает» ли обновление SSD физически или просто портит данные.
• Пользователи обсуждают ответственность Microsoft и риски откладывать обновления.
• Некоторые советуют LTSC-версии Windows или Linux, другие — вообще не обновляться.

• Отложено: удаление каталога docker.io/bitnami перенесено на 29 сентября.
• Браун-ауты: 28 авг, 2 и 17 сентября по 10 образов будут недоступны 24 ч.
• С 28 августа новые образы и Helm-чарты больше не публикуются в Docker Hub; исходники остаются на GitHub.

Что меняется

Образы и чарты переезжают в Bitnami Legacy; для продолжения работы обновите CI/CD и кластеры.

Как действовать

1. Bitnami Secure Images (BSI) — рекомендованный путь; часть бесплатна только для dev/test, продакшен требует подписки.
2. Bitnami Legacy Registry — временное решение.

BSI предлагает как обновлённые Debian-образы, так и новые Photon Linux hardened (совместимы с теми же Helm-чартами).

• Broadcom/Bitnami прекращают публикацию готовых образов в публичных регистри, оставляя только исходники под Apache-2, и требуют платной подписки для OCI-хостинга.
• Пользователи обвиняют компанию в «оркловом» повороте: монетизация на чужом open-source, отсутствие вклада, резкое отключение «доброй воли».
• Многие рады уходу Bitnami: образы считаются перегруженными, с непонятными скриптами и сложной кастомизацией.
• Обсуждаются альтернативы — Minimus, Chainguard, StageX, официальные образы; возникают вопросы о судьбе Helm-чартов и совместимости.
• Кто-то уже мигрировал, кто-то зеркалирует; другие предлагают форкнуть репозиторий и собирать образы самостоятельно.

• Bitwig Studio 6 в бета-доступе; финал — осенью.
• Главное — улучшено редактирование:
  • A → режим автоматизации одного параметра.
  • Жесты, спрэд, холд, кривые.
  • Новые инструменты: Spray Can, Audition, улучшенный Pencil.
  • Automation Clips как отдельные клипы с привязкой к нотам/аудио.
  • Редактирование выражений прямо на нотах.
  • Одновременное редактирование нескольких клипов.
• Clip Aliases — мастер-шаблон, влияющий на все связанные клипы.
• Общие тональности проекта и Adapt to Key, новые Grid-модули Scale/Root.
• Обновлённый UI: палитра инструментов, авто-zoom, динамичные заголовки.
• При открытии старого проекта создаётся резервная копия с версией в имени.
• Бета бесплатна при активном Upgrade Plan; инструкции и ноты релиза:
  Release Notes | What’s New

• Bitwig хвалят за встроенные инструменты/эффекты, Linux-поддержку, модульность и быстрое развитие.
• Некоторые упомянули альтернативы: FOSS-DAW Zrythm и live-coding-инструменты Strudel, Tidal Cycles, Renoise.
• Была дискуссия о нехватке AI-функций (stem-separation, ML-тегирование) и о «спектральном скандале» с YouTube-контентом.
• Пользователи делятся опытом перехода с Ableton/Logic и обсуждают страх «исчезновения» молодого DAW.

В декабре 2020-го Хектор Мартин запустил Asahi Linux, а я, работая над Panfrost, лишь хотел подсказать. В итоге купил Mac mini и начал реверсить GPU. Через пару недель нарисовал треугольник, потом — компилятор шейдеров, а после сессии за несколько дней поднял OpenGL-драйвер.

Год улучшал драйвер, пока игры не пошли под macOS. Параллельно Asahi Lina писала kernel-драйвер; в декабре 2022-го у нас впервые заработала графика в Linux.

В 2023-м, заканчивая универ, я решил:

• довести M1-драйвер до ума;
• сделать полноценный OpenGL 4.6 и Vulkan;
• запустить Proton-игры.

Через месяц после выпуска — OpenGL 3.1, затем ES 3.1. Добавил эмуляцию geometry/tessellation, в январе 2024-го сдал OpenGL 4.6. Vulkan 1.3 прошёл за пару недель, 1.4 вышел в день публикации спецификации. Karol Herbst добавил OpenCL 3.0. Подключил sparse-текстуры — заработал Direct3D 12 через Proton.

Цели выполнены: драйверы в Mesa, игры идут, миф о несовместимости Vulkan с Apple развеян.

• Alyssa за 5 лет с нуля довела Vulkan-драйвер для Apple Silicon до upstream, чем вдохновила всё open-source-сообщество.
• Учёба, работа в Collabora и «хобби»-проект — комментаторы поражаются, как она всё успевала.
• С августа она в Intel и, судя по резюме, занимается open-source-графикой Xe-HPG.
• Многие жалеют, что она уходит из Asahi, но считают переход новым вызовом, а не «уходом».
• Появились вопросы о будущем Asahi на M3/M4 и о том, почему Apple не мешает проекту, в отличие от других.

• Framework Laptop 16 — предзаказы открыты
• Desktop — обзор, запчасти, документация, конфигуратор
• Laptop 12 — обзор, запчасти, документация, конфигуратор
• Laptop 13 — обзор, запчасти, документация, конфигуратор
• Laptop 16 — обзор, запчасти, документация, конфигуратор

Магазин

• Всё
• Outlet
• Ноутбуки
• Десктопы
• Материнки
• Модули расширения
• Память и накопители
• Клавиатуры
• Запчасти
• Инструменты
• ПО
• Мерч

Поддержка

• Linux
• Форум
• База знаний
• Запрос в поддержку

О компании

• О нас
• Устойчивость
• Блог
• Вакансии

• Пользователи жалуются на отсутствие WWAN-модуля, мелкие стрелки и нехватку клавиш Home/End.
• Радуются AMD-видеокартам как более «линуксовским», но спорят о проблемах NVIDIA.
• Цена новой сборки (≈ $4000) вызывает шок: «дороже, чем игровой ROG с RTX 3080».
• Вопрошают о реальной экономике модульности, сроках поставки в Японию и о OLED-экранах.
• Любители Linux спрашивают о «из коробки» и просят ThinkPad-стильный trackpoint.

Разработка собственной ОС освобождает от ограничений коллективной работы и позволяет экспериментировать с необычными паттернами. Вдохновлённый статьёй LWN «Object-oriented design patterns in the kernel», я реализовал все сервисы ядра через «виртуальные таблицы» (vtables) — структуры с указателями на функции, обеспечивающие полиморфизм на чистом C.

Базовая идея

struct device_ops {
    void (*start)(void);
    void (*stop)(void);
};

struct device {
    const char *name;
    const struct device_ops *ops;
};

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

Применение в моей ОС

• Сервисы: сетевой менеджер, оконный сервер и др. описываются структурой

struct service_ops { void (*start)(void); void (*stop)(void); void (*restart)(void); };

Позволяет из терминала запускать/останавливать потоки без хардкода.

• Планировщик: интерфейс yield, block, add, next реализуется разными стратегиями (round-robin, SJF, FIFO). Политику можно заменить без пересборки ядра.
• Файлы: как в Unix, «всё есть файл». Сокеты, устройства и обычные файлы предоставляют одинаковые read/write, скрывая сложность реализации.

Модули ядра
Такой подход легко расширяется динамически загружаемыми модулями-драйверами, как в Linux.

• Обсуждение показывает, что в ядре Linux и других проектах на C давно применяют «объектно-ориентированные» приёмы через структуры с указателями на функции (таблицы виртуальных методов).
• Некоторые считают это удобным и экономным по памяти, другие — источником проблем с читаемостью, отладкой и оптимизацией.
• Упоминаются готовые микро-фреймворки (co2, carbon) и примеры из tmux, где такие паттерны уже используются.
• Спор идёт о необходимости явного параметра this: одни ценят прозрачность, другие — «сахар» неявного this в C++/Java.
• Вопрос «почему бы не перейти на C++/другой язык» сводится к контролю над памятью, отсутствию «магии» и возможности оставаться на C ради производительности и простоты.

Краткое резюме: пределы точности NTP в Linux

• Цель – синхронизировать часы Linux-систем с погрешностью < 1 мкс (желательно < 10 мкс) для корректных распределённых трассировок.
• Результат – большинство узлов держатся в пределах ~500 нс; улучшить без точной инженерии сложно.

Основные ограничения

1. GPS не идеален

   • 3 GPS-приёмника на столе расходятся до ±200 нс; даже топовые модули дают ~5 нс джиттера.
   • Чтобы уложиться в 50 нс, нужны одинаковые длины антенных кабелей и пр.

2. Сеть

   • Любой «умный» коммутатор или маршрутизатор легко добавляет 200–300 нс систематической ошибки.
   • RTT в моей сети 20–30 мкс, поэтому цель < 1 RTT.

3. NIC и драйверы

   • Intel E810 – отлично, X710 – хорошо, Mellanox ConnectX-5 – сойдёт, ConnectX-3/4 – на грани, Realtek – не надо.
   • Разница в драйверах и аппаратных метках времени (timestamps) доходит до сотен наносекунд.

4. Системные задержки

   • Случайные «затыки» из-за SMBIOS/PM: 100–1000 мкс без предупреждения.
   • Дешёвые mini-PC показали 1300–2000 нс дрейфа, но два других – всего 20–50 нс. Серверное «железо» стабильнее.

Практические цифры

• Типовая синхронизация по локальному GPS-источнику через Chrony: ~500 нс.
• В лабораторных условиях Chrony демонстрирует < 100 нс, но это исключение.

Вывод
Без специализированного оборудования, калибровки кабелей и тщательного выбора NIC/драйверов 200 нс – реалистичный потолок для обычной сети.

• Участники считают, что автор путает цели и средства: ему нужна не абсолютная точность, а согласованность логов между машинами.
• Критика: в посте игнорируют PTP, аппаратное тайм-стемпинг, saw-tooth коррекцию GPS и другие ключевые приёмы.
• Несколько человек подтверждают, что Chrony + хорошие NIC дают суб-микросекунды без PTP, если задача не требует <200 нс.
• Уточняют, что GPS-модули нужно выводить в stationary mode и калибровать сутками для десятков наносекунд.
• Появляются примеры, где такая точность действительно нужна: синхронизация базовых станций, HFT, триангуляция радиосигналов.

• Apple опережает благодаря вертикальной интеграции: единое ядро macOS/iOS, SoC-архитектура, память на подложке, отсутствие легаси-инструкций и тонкая настройка всего стека «железо-ОС-приложения».
• x86-платформе мешают обратная совместимость, разные OEM-вендоры, сменные модули памяти (DDR вместо LPDDR) и необходимость оптимизировать под сотни конфигураций.
• AMD уже приблизилась: Ryzen AI Max 395+ в Framework Desktop почти догоняет M4 Pro по производительности и энергоэффективности, но пока не вышла в лэптопах.
• На практике большую роль играет ОС: Linux-ноутбуки часто теряют до 2× времени автономности из-за драйверов, Chrome, GPU-ускорения и отсутствия агрессивных профилей энергосбережения.
• Итог: догнать M1/M4 «на бумаге» уже почти возможно, но сопоставимый реальный опыт потребует либо закрытой экосистемы, либо множества доработок в прошивке, драйверах и ПО.

Почему я перешёл на MiniPC

Пару лет экспериментов убедили: это моё будущее.

Плюсы

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

• Компактность
  Прячется за ТВ, помещается на ладонь, легко переносится.

• Энергоэффективность
  20–50 Вт под нагрузкой, 6–12 Вт в idle. Для 24/7-сервисов выгодно и экологично. ARM/RISC-V обещают ещё меньше энергии.

• Специализация
  Один тип MiniPC не универсален, но набор из разных закрывает все задачи:

  • обычные — офис/браузер;
  • 4–6 LAN-портов — роутер, фаервол, VPN;
  • 4–6 M.2 — компактный NAS (до 20 ТБ);
  • мощный — хост контейнеров и «облако»;
  • Mac mini — macOS без отказа от Linux.

• Простота сборки
  «Монолит» из одного большого ПК требует редкой материнки, кучи PCI-устройств, корпуса с отсеками, сложной логистики и возвратов. Несколько MiniPC решают то же быстрее и дешевле.

• Участники активно обсуждают, как Mini-PC стали «новыми домашними серверами»: дешёвые, экономные (6–50 Вт), легко кластеруются под Proxmox/K8s и заменяют дорогое «энтерпрайз» железо.
• Популярны бывшие корпоративные NUC/HP/Lenovo и китайские 5560U/16 ГБ за $200–300; их ставят за TV, в туалет, за лазер, за StepMania — «дешевле, чем облако».
• Главные боли: шум (особенно в «геймерских» версиях), неремонтопригодность (паяная RAM/CPU, кастомные кулеры), высокий процент брака дешёвых китайцев и отсутствие апгрейдов.
• Мечтают о «тихом Mac-mini-размере» с RTX 4060/780M для игр, но физика (300 Вт TDP) и цена (~$2000) пока не позволяют; вариант — ПК в соседней комнате + длинный кабель/KVM.
• Valve, по мнению многих, была права с идеей Steam Machine, но рано и промахнулась в Linux-играх; новая попытка в 3–5 лет, возможно, совместит Proton, Mini-PC и приставочную форму.

TuneD — служба тонкой настройки Linux.

• Отслеживает устройства через udev, применяет профили, управляется из CLI и D-Bus.
• Поддерживает sysctl, sysfs, параметры ядра, плагины.
• Работает без демона на ограниченных системах.
• Всё хранится в одном профиле, без разбросанных скриптов.

Профили

• Наследуются: общий HTTP-шаблон → Apache, Nginx.
• Полный откат изменений.
• Готовые пресеты: высокая пропускная способность, низкая латентность, энергосбережение, SAP, dBase и др.

Документация

• Старая: Fedora Power Management Guide.
• Новая: GitHub.
• Презентация: DevConf 2019.

Скачать
GitHub releases.

Баги
GitHub issues.

Разработка
GitHub.
PR или письма на power-management@lists.fedoraproject.org.

Лицензия
GPL v2+.

• TuneD хвалят за экономию до 40-55 Вт и удобство на рабочих станциях, но на серверах результат «50/50»: иногда отключают и переходят на собственные скрипты.
• Есть адаптер под power-profiles-daemon, поэтому переключать профили можно из GNOME/KDE.
• Критика: дефолтные настройки неверно биндят IRQ для сети, а сам демон написан на Python, что вызывает сомнения в «производительности» инструмента для управления производительностью.
• Нет встроенного ограничения заряда батареи (как в TLP), поэтому для ноутбуков TuneD может быть не идеален.
• Пользователи хотели бы утилиту, которая после установки Linux сразу показывает, что не работает (suspend, GPU, Wi-Fi, диск), но такой «one-shot» диагностики пока нет.

Adobe Reader vs SumatraPDF

• Adobe Reader 25.x (Win11, 64-bit): 687 МБ
  — встроенный «ИИ», автообновления, реклама Acrobat, два интерфейса.

• SumatraPDF 3.5.2: 8 МБ
  — нет «ИИ», автообновлений, рекламы; ставится через scoop.

График роста размера инсталлятора Adobe Reader за годы:

• Adobe Reader раздут до 600 МБ, медленный, навязчиво предлагает платные функции и ставит сторонний софт (McAfee).
• Подавляющее большинство пользователей отказались от него в пользу браузеров, macOS Preview, SumatraPDF, PDF-XChange, Okular и других лёгких альтернатив.
• Логарифмический масштаб графика скрывает реальный рост размера: Reader стал в 83 раз больше Sumatra.
• Для Windows рекомендуют SumatraPDF и PDF-XChange, для Mac — Preview и Skim; Linux-пользователи используют zathura, evince или Okular.

• DGX Spark — компактный «суперкомпьютер» на базе процессора Grace Blackwell, помещающийся на столе.
• Поддерживает обучение и инференс ИИ-моделей любого размера благодаря архитектуре Grace Blackwell и 128 ГБ унифицированной памяти.
• Подключается к DGX Cloud для масштабирования задач и работает в экосистеме NVIDIA AI Enterprise.
• Поставляется с полным стеком ПО: CUDA, cuDNN, TensorRT, NeMo, RAPIDS и другими фреймворками.
• Подходит исследователям, стартапам и инженерам, которым нужна локальная мощность без серверной.

• Jetson Thor и DGX Spark работают на зафиксированном ядре Linux от NVIDIA на Ubuntu 20.04, обновления ограничены, как на китайских SBC.
• Spark: 1000 FP4-TOPS, 128 ГБ LPDDR5x, 273 ГБ/с пропускная способность, цена $3999; по $/производительность проигрывает 5090 и Thor.
• Узкое место — низкая пропускная способность памяти: в 4 раза меньше RTX 4090 и в 8 раз меньше M4 Max, что ограничивает обучение и крупные LLM.
• Устройство позиционируется как devkit для прототипирования и дообучения, а не как универсальный ПК; потребление и дата выхода не раскрыты.
• Многие считают цену завышенной и ждут сравнения с будущими Mac Studio M4/M5 Ultra и AMD Strix Halo.

Итоги моего ухода с Windows на Linux в эпоху анти-клиента

Профессионал с 25-летним стажем, я окончательно перешёл на Linux в 2023 г. и уже два года не возвращаюсь.
Windows 11 стал рекламной площадкой: Copilot, Recall, OneDrive навязываются и крадут данные без спроса.
Подписки вместо покупки, «облачные» файлы без согласия — всё это разрушает доверие.

Технически Linux сложнее, но свобода стоит усилий.
Европа (Digital Markets Act) и движения вроде StopKillingGames и RightToRepair дают надежду.

Ключевой вывод: контроль над купленным — основа личной свободы.

• Пользователи массово переходят на Linux из-за разочарования Windows 10/11 и улучшений десктоп-опыта.
• В семьях и малых бизнесах Linux уже заменяет Windows на ноутбуках и POS-терминалах, несмотря на «налог Microsoft» за предустановку.
• Среди оставшихся препятствий: игры с античитом, Adobe Creative Suite, Citrix, управление питанием/тачпадом, «виснут» при нехватке RAM.
• На работе Linux-доступен по запросу, но Word/Excel/PowerPoint и их форматы всё ещё тормозят миграцию SMB.
• Сообщество делится лайфхаками: Bee-link-мини-ПК вместо dual-boot, earlyoom/OOM-kill, AMD-видеокарты для игр, KVM-переключатели.

clearcam — добавляет к любой RTSP-камере или iPhone детекцию, трекинг объектов и push-уведомления.
Работает на Raspberry Pi, Linux, macOS, Windows; Python 3.8+.

Ключевые функции

• Детекция людей, животных, машин, посылок (YOLOv8).
• Трекинг объектов между кадрами.
• Уведомления в iOS/Android (Firebase).
• Запись коротких клипов при событии.
• Web-интерфейс для просмотра и настройки.

Быстрый старт

git clone https://github.com/roryclear/clearcam
cd clearcam
pip install -r requirements.txt
python clearcam.py --source rtsp://user:pass@ip/stream

Настройка

• config.yaml: камеры, классы объектов, чувствительность, токен Firebase.
• Telegram-бот для команд «/arm», «/disarm».

Примеры

• Дом: уведомление, если кто-то вошёл во двор.
• Офис: отслеживание доставленных посылок.

• Обсуждали два решения: новый проект Clearcam и известный Frigate; Clearcam проще ставится, но удалённый просмотр и уведомления требуют подписки, тогда как у Frigate всё бесплатно.
• Пользователей смущает, что Android-версия Clearcam пока требует регистрации через iOS и Apple Pay.
• Ищут камеры без шпионского ПО: советуют Axis, Reolink, Ubiquiti, а также самоделки на open-source прошивке Thingino.
• Разбирались, как детектировать машины, не остановившиеся у знака «стоп»: предложили измерять скорость между двумя точками и задавать порог.
• Выяснили, что термин «CCTV» всё ещё используют для любых камер наблюдения, хотя технически это уже IP-видео.

• Справочник Valve 2012 года, восхваляемый как образец «плоской» структуры, на деле создавался как рекрутинговый брошюрный продукт и не раздавался сотрудникам.
• Участники спорят: оправдан ли 30 % сбор Steam, действительно ли компания всё ещё «без начальников» и не превратилась ли в «печатный станок по продаже шляп».
• Некоторые подтверждают, что культура внутри Valve всё ещё соответствует тексту (столы на колёсах, отсутствие менеджеров), другие считают это утопией и прикрытием монополии Steam.
• Упоминают вклад Valve в Linux-гейминг (Proton, Steam Deck) и отсутствие крупных игровых релизов после 2012 года, кроме Half-Life: Alyx и Deadlock.

Купи быстрый процессор

Современные CPU стали шокирующе быстрыми, но большинство по-прежнему используют старые мобильные чипы, теряя продуктивность.

Подписка на AI-инструменты вроде Cursor стоит $480/год, а топовый Ryzen 9 9950X — всего $500. Амортизация за 3 года = $170/год: дешевле, чем AI, и выгода очевидна.

Бенчмарки

• Корпоративный ноутбук 2024 (i7-1165G7, 2020 г.)
• Лучший ThinkPad 2024 (Ryzen 7840U)
• Десктоп 2025 (Ryzen 9950X)

Разница — >10× на компиляции ядра Linux и TLS-операциях. 3 с против 30 с или 300 мс — это кардинально меняет опыт.

Правило:

• Десктоп ≈ 3× быстрее ноутбука
• Топ-CPU 2025 ≈ 3× быстрее топа 2022
• Новые облачные VM тоже 2-3× быстрее за ту же цену

Если вы оправдываете AI-подписку, оправдайте и лучший инструмент — быстрый CPU.

• Почти все согласны: «быстрый процессор = меньше ожидания компиляции → выше продуктивность», и ROI для старших разработчиков окупается за недели.
• Но выгода сильно зависит от задач: многие уже компилят в облаке/сервере, а фронтенд-сборки всё равно тормозят из-за однопоточных инструментов.
• Некоторые 10-летние CPU (i7-4770, Phenom II) всё ещё «достаточно быстры», если добавить RAM и SSD; апгрейд не всегда оправдан.
• Ноутбуки ограничены теплопакетом: «топ-чип в лэптопе ≠ тот же чип в десктопе».
• Итог: берите максимально быстрый десктоп, если компилируете локально; если работаете в облаке — экономьте деньги и нервы.

Omarchy — мой новый проект: готовая, «моя» версия Arch + Hyprland. Устанавливаешь — получаешь то, что я использую каждый день.

Hyprland красив, но «из коробки» пуст: нет даже экрана блокировки. Omarchy решает это: красивые конфиги и нужный софт уже на месте.

Это не замена Omakub (Ubuntu), а продвинутый путь для тех, кому Arch ближе.

Linux на десктопе? Valve, Steam Deck, креаторы вроде PewDiePie и проекты вроде Hyprland делают его всё более заманчивым.

• Вышел Omarchy 2.0 — готовый Arch-ISO с Hyprland, ставится за ~5 минут.
• Большинство обсуждают Hyprland: кто-то в восторге от тайлинга и «веселья» Linux, кто-то считает слишком «голым» и сложным.
• Часть пользователей предпочитает плавующие окна или другие WM; другие перешли с macOS на Fedora/Gnome.
• Упоминаются альтернативы: NixOS, Bluefin, Omakub, Zorin, Rectangle/AeroSpace на macOS.
• Некоторые критикуют Hyprland за конфликты в сообществе и «токсичность», но число пользователей растёт.

Краткий итог тестов LLM для личных задач

• Цель: найти быструю и дешёвую модель для простых вопросов по Rust, Python, Linux и быту.
• Данные: 130 реальных запросов из bash-истории, разбитые на программирование, администрирование, объяснения, общие знания.
• Платформа: OpenRouter через собственный Rust-клиент ort.
• Тестовые модели: Claude-4 Sonnet, DeepSeek-chat-v3, DeepSeek-r1, Gemini 2.5 Flash/Pro, Kimi-k2, GPT-OSS-120B, Qwen3 235B (обычный и thinking), GLM-4.5, а также Mercury-Coder, Devstral, Qwen3-Coder для кода.

Выводы

• Почти все модели справляются; различия в качестве минимальны.
• Критерии победы: цена и скорость. Запросы стоят доли цента, но латентность варьируется в десятки раз.
• Закрытые модели не лидируют: Gemini Pro самый дорогой и многословный; Flash быстрее всех, но не всегда лучше.
• Режим «рассуждений» почти не нужен, кроме творческих заданий (стихи).
• Победители по категориям
  • Программирование: Mercury-Coder (сверхбыстрый диффузионный), DeepSeek-r1, GLM-4.5.
  • Сисадмин: Gemini 2.5 Flash.
  • Объяснения: Qwen3 235B.
  • Общие знания: GPT-OSS-120B.

Инсайт: для рутинных задач выбирайте самую дешёвую и быструю модель, которая «достаточно хороша».

• Google Gemini 2.5 Flash признан «рабочей лошадкой»: быстро, дёшево, мультимодален и способен пережёвывать 100 k запросов за €30.
• Большинство участников жалуются на «сговор» моделей: при творческих задачах 6 из 11 LLM выдают один и тот же ответ, что убивает креатив.
• Локальный запуск: на Mac Mini 64 ГБ уверенно работают модели < 32 B; фаворит — gpt-oss-20b (11 ГБ RAM) и семейство Qwen 3.
• Для выбора «одной на всё» многие выбирают deepseek-chat-v3-0324 как компромисс скорость/цена/качество.
• Трения с API: OpenAI требует KYC, Claude доступен не везде, поэтому кто-то использует Kagi, Perplexity или OpenRouter, чтобы «пощупать» все модели без лишних ключей.

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

Изоляция и производительность
Аппаратные уровни привилегий, IOMMU, KVM, cgroups и namespaces обеспечивают изоляцию ВМ. Однако для скорости всё чаще используют прямой доступ к устройствам (DPDK, vDPA), что снижает контроль ОС и усиливает зависимость от железа и прошивок.

Решение: доверенные устройства
AMD SEV-TIO и стандарт TDISP позволяют гостю криптографически убедиться в подлинности устройства и разрешить ему прямой доступ к зашифрованной памяти, избегая медленных bounce-буферов. Реализуется через SR-IOV: физическое устройство создаёт множество виртуальных функций, каждая из которых может быть «доверенной» для конкретной конфиденциальной ВМ.

• Критики считают, что Confidential Computing (CC) — это скорее маркетинговый трюк облачных провайдеров, чем реальная защита: аппаратная основа часто уязвима и не может быть исправлена.
• Даже при шифровании памяти вы всё равно работаете на чужом железе, которое теоретически могут модифицировать для сниффинга или извлечения данных.
• Для многих CC — способ «галочки» под GDPR, особенно в медицинских исследованиях, но реальная польза пока минимальна.
• Apple реализовала собственную версию CC качественно, но она закрыта и только для экосистемы Apple.
• Участники соглашаются: если ваша модель угроз не позволяет доверять провайдеру, используйте физические серверы; «доверие» в облаке всегда остаётся условным.

nitro — миниатюрный, но гибкий init и супервизор процессов.

Назначение

• init для встраиваемых, десктопных и серверных Linux-систем
• initramfs, контейнеров (Docker, Podman, LXC, K8s)
• непривилегированный демон на POSIX

Конфигурация — каталог скриптов (по умолчанию /etc/nitro).

Требования

• Unix-сокеты
• tmpfs или записываемый /run

Плюсы

• Всё состояние в RAM, работает на read-only root.
• Событийная модель без polling.
• Ноль аллокаций и ограниченных fd во время работы.
• Один статический бинарник + опциональный nitroctl.
• Сервисы — просто каталоги со скриптами, компиляция не нужна.
• Перезапуск, логирование, цепочки логов, независимость от времени.
• Запускается на FreeBSD через /etc/ttys.

Сервис

Каждый подкаталог /etc/nitro может содержать:

• setup — предзапуск, должен завершиться с 0.
• run — основной процесс (не должен завершаться).
• finish — пост-обработка, получает код выхода и сигнал.
• log → symlink на другой сервис для логов.
• down — не поднимать автоматически.
• Имена ≤ 64 символов, без /, ,, переводов строк.
• Каталоги с @ в конце игнорируются (параметризованные сервисы).

Специальные сервисы

• LOG — лог по умолчанию.
• SYS/setup — перед стартом остальных.
• SYS/finish — перед остановкой всех.
• SYS/final — после завершения всех процессов.
• SYS/fatal — при критической ошибке.
• SYS/reincarnate — вместо выключения (полезно для initramfs).

Параметризованные сервисы

Каталог foo@ + symlink foo@bar → запуск foo@/run bar.
nitroctl up foo@baz запустит foo@/run baz даже без symlink.

Жизненный цикл

1. Подъём: SYS/setup, затем все непомеченные down.
2. Работа: перезапуск при падении (пауза 2 с при частых падениях).
3. Останов: nitroctl Shutdown/Reboot → SYS/finish → SIGTERM (7 с) → SIGKILL → SYS/final → reboot/off/exit.

Управление nitroctl

nitroctl [команда] [сервис]

• list — состояния, pid, uptime, код выхода.
• up/down — запустить/остановить (SIGTERM или down-signal).
• start/stop/restart — с ожиданием успеха.
• p/c/h — SIGSTOP/SIGCONT/SIGHUP.

• Участники сравнивают Nitro с runit, s6, dinit и systemd: общие черты — минимализм, отсутствие декларативных зависимостей, ручная настройка порядка запуска.
• Некоторые считают Nitro скорее «голым» супервизором процессов, чем полноценной init-системой из-за отсутствия управления ресурсами, пользователями и параллельного запуска.
• Обсуждаются контейнерные кейсы: одни считают наличие init внутри контейнера избыточным, другие — необходимым при форке процессов.
• Упоминаются альтернативы: собственные минимальные init-системы на C и Rust, а также новый модульный подход в NixOS.
• Критика имени: «nitro» уже занято AWS Nitro, Nitro.js и другими проектами; предлагают сменить название.

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

Ключевые возможности

• Качественные графики и интерактивные диаграммы в пару кликов
• Статистика, регрессия, аппроксимация и фитинг пиков
• Интерактивные блокноты Python, R, Julia и др.
• Извлечение данных из изображений и поддержка потоковых данных
• Импорт/экспорт множества форматов
• Windows, macOS, Linux, FreeBSD, Haiku

Свежие новости

• 2.12.1 (18 авг 2025) — мелкие улучшения и исправления
• 2.12 (28 апр 2025) — крупное обновление после долгой разработки
• Дек 2024 — обновлённое руководство пользователя

Скачать | Возможности

• Участники обсуждают LabPlot как FOSS-альтернативу Origin/JMP/Tableau для научного графика.
• Сравнивают: гибкость ggplot2, устарелость Excel/SAS, удобство GUI для не-программистов.
• Плюсы: drag-and-drop, встроенный импорт CSV/TSV, лицензия GPLv2+.
• Минусы: пока только SQLite, нет прямого REST/S3/Iceberg, неясно, как быстро копировать стили.
• Целевая аудитория — инженеры и учёные, которым нужен GUI-построитель графиков без кода.

Почему античиты не работают в Linux

Доля геймеров на Linux растёт благодаря Steam Deck и надоедливым «фичам» Windows. Однако почти все сетевые хиты с античитом не запускаются или не подключаются к серверам: PUBG, Call of Duty, Rust, R6 Siege, EA FC 24, Destiny 2, Valorant, League of Legends и даже FACEIT/ESEA для CS2.

Как работают читы и античиты

Чит либо внешний процесс, читающий/писующий память игры, либо внедрённая DLL. ОС не даёт процессам трогать чужую память благодаря виртуальному адресному пространству: каждая программа «думает», что владеет всей ОЗУ, а процессор и ядро переводят виртуальные адреса в реальные.

Античиты борются с этим двумя путями:

1. Пользовательский режим – сканируют память, читают файлы, ловят подозрительные потоки. Легко обойти, если у чита есть root-доступ.
2. Ядро (kernel) – драйвер внутри ядра Windows имеет полный доступ к железу и памяти, может скрывать свои структуры и блокировать вмешательство. Vanguard, EAC, BattlEye и пр. работают именно так.

Почему это невозможно в Linux

• Linux — открытая система. Любой может собрать своё ядро, поставить патч, изменить ABI.
• Античиту нужен стабильный, неизменяемый и закрытый интерфейс ядра. В Linux этого нет: модуль, собранный под 6.9, не загрузится под 6.10, а пользователь может вообще отключить модульные загрузки.
• Даже если разработчик выпустит проприетарный модуль, сообщество его не примет: безопасность, GPL-лицензия, репутационные риски.
• Попытки «запечатать» Linux (secure boot + immutable образ) противоречат свободе системы и всё равно не гарантируют, что пользователь не пересоберёт ядро без проверок.

Что можно сделать

1. Играть в поддерживаемые игры: Apex, Fortnite, CS2, Elden Ring и др. уже работают через Proton.
2. Двойная загрузка или VFIO-виртуалка – запуск Windows в виртуальной машине с проброской GPU (сложно, но работает).
3. Облачный гейминг – GeForce NOW, Xbox Cloud и т.д.
4. Ждать – пока разработчики не придумают античит, который не требует закрытого ядра (маловероятно).

Вывод: пока Linux остаётся открытой системой, современные kernel-level античиты там жить не смогут.

• Критики считают, что анти-чит на уровне ядра — это по сути rootkit, который подрывает безопасность и конфиденциальность.
• Многие предлагают альтернативы: доверительные сообщества, выделенные игровые машины, серверные проверки или облачные платформы.
• Подчеркивается, что Linux по дизайну даёт пользователю полный контроль, что делает невозможным эффективный, но инвазивный анти-чит.
• Некоторые игроки готовы пожертвовать безопасностью ради «честной» игры, но большинство участников обсуждения считают такой обмен неприемлемым.

simpleide — лёгкая IDE для Visual Basic, работает на Linux и использует нативный .NET.
Позволяет писать, компилировать и запускать VB-код без Windows.

• Обсуждали SimpleIDE — лёгкий open-source IDE для VB.NET на Linux (GTK# 3, .NET 8).
• Пользователи делятся ностальгией по VB, но отмечают падение популярности языка и отсутствие drag-and-drop GUI-редактора.
• Кому нужен .exe под Windows 11, советуют Visual Studio или Rider + Avalonia/C#; SimpleIDE заточен под Linux.
• Автор проекта за два месяца «с нуля» написал IDE с Claude и готовит библиотеку кастомных виджетов.
• Поднимается тема «AI-IDE нового поколения» и альтернатив вроде Gambas, Lazarus, React Native и веб-технологий.

Переход с macOS на Arch Linux (Omarchy)

После 15 лет на MacBook Pro M1 Max я пересел на недорогой Lenovo ThinkBook 14 G7 с Omarchy — обвязкой над Arch Linux. Первый месяц использования (с перерывами на ремонт) и две полные недели — вот краткий итог.

Подготовка

Перед переходом проверил, что всё критичное доступно:

• Obsidian, fuzzy-файловый поиск, скриншоты, фото-редактор, f.lux, календарь в трее, гибернация.
• Единственное, что не решено — полный бэкап системы (Time Machine пока не нашёл аналога).

Что потерял и что приобрёл

• Скриншоты: Snagit пока не заменил; быстрый OCR и библиотека скринов отсутствуют.
• «Просто работает»: иногда ломаются шорткаты, но это цена свежести Omarchy и моей неопытности.
• Аккумулятор и шум: хуже, чем у M1, но принимаю за свободу настройки.
• Бэкап: пока ручной; после случайного слома /etc/sudoers понял, что нужен надёжный механизм.
• Синхронизация: Sync.com → Filen.io — безболезненно.

Omarchy

Omarchy — это Arch + готовые дотфайлы, Wayland (Hyprland), пакетный менеджер yay, и куча скриптов. Всё ставится одной командой, затем можно тонко под себя.

Опыт и выводы

• Аппарат: ThinkBook дешевле, но качество корпуса и экрана заметно хуже MacBook.
• Скорость работы: после настройки переключение между проектами стало мгновенным (Hyprland + workspaces).
• Обучение: за месяц освоил pacman, systemd, waybar, rofi, hyprland.conf — получил удовольствие от процесса.
• Следующий шаг: настроить полный образовый бэкап (Btrfs snapshots + rsync), чтобы не бояться экспериментов.

Итог: Linux требует времени, но даёт полный контроль и удовольствие от «собери сам».

• Пользователи хвалят «железо» Apple: трекпад, экраны, батарею, отсутствие шума вентиляторов и долговечность (5-13 лет).
• Многие жалуются на macOS: странная логика, невозможность мгновенного переключения рабочих столов, «мусор» вроде .DS_Store.
• Linux-энтузиасты ищут ноутбуки с ARM, хорошими драйверами, металлическим корпусом и большой батареей, но пока не находят идеального аналога MacBook.
• Omarchy (Arch-дистрибутив) упрощает установку Arch, но вызывает сомнения в долгосрочной поддержке.
• Часть разработчиков использует Mac как «красивый UNIX» и SSH-доступ к мощным Linux-серверам, чтобы совместить плюсы обеих систем.

AnduinOS — лёгкий, приватный, бесплатный дистрибутив на базе Ubuntu.
ISO 2 ГБ, GNOME-оболочка, Flatpak-приложения, никакого слежения.
Совместим с пакетами Ubuntu, подходит для работы, игр, сервера и обучения.

Версии

• LTS 1.1 (Noble Numbat) — до апреля 2029, GNOME 46, ядро 6.11, стабильность.
• Standard 1.3 (Plucky Puffin) — до января 2026, GNOME 48, ядро 6.14, новейшие функции.

Ссылки

• Скачать | Документация | Исходники | Поддержать

«Переход с Windows прошёл безболезненно, система лёгкая и красивая» — пользователи.

• Многие спутали название «AnduinOS» с «ArduinoOS».
• Это одиночный проект китайского инженера Microsoft: ремикс Ubuntu с GNOME, стилизованным под Windows 11.
• Критика: «distro-дистро-дистро» не заслуживает звания OS, не ясен уникальный посыл по сравнению с Mint/Ubuntu.
• Плюсы: простая установка Flatpak, может помочь консервативным пользователям перейти с Windows.
• Минусы: нет ARM-сборки, в скриншотах замечен сомнительный WPS Office, отсутствует описание отличий от Ubuntu.

Без futex всё тленно

Книга The Art of Multiprocessor Programming (2-е изд., 2021) считается канонической, но она обходит стороной futex — ключевой примитив современной многопоточности. Это упущение делает пособие бесполезным для практиков.

Futex ≠ mutex
Название происходит от «fast userspace mutex», но futex — это не мьютекс, а основа для всех высокоэффективных примитивов синхронизации. До него всё строилось на громоздких System V IPC, которые не масштабировались: при 1000 потоков futex в 2002-м оказался в 20–120 раз быстрее sysv-блокировок. Windows и macOS добавили аналоги только в 2012 и 2016 гг.

Суть futex
Он разделяет блокировку и ожидание/пробуждение:

• В user-space проверяем состояние; если свободно — захватываем без системного вызова.
• При конфликте вызываем futex_wait(addr, expected), засыпаем в ядре на конкретном адресе.
• Пробуждение — futex_wake(addr, n), где n обычно 1 или «все».

Передаваемое в wait значение защищает от «просыпания» после уже случившегося события: если память изменилась, системный вызов мгновенно возвращает ошибку.

Такой подход убирает лишние системные вызовы и позволяет строить быстрые мьютексы, rw-lock’и, семафоры и пр. без поллинга и экспоненциальных бэкоффов.

Итог
Любая современная библиотека (pthreads, C++ std::mutex, Rust std::sync) опирается на futex. Учебник, игнорирующий этот примитив, не готовит к реальной разработке.

• Futex — это быстрый примитив синхронизации, который экономит системные вызовы при отсутствии конфликтов и не требует выделения ядром объектов.
• В отличие от Benaphore и старых SysV-механизмов, futex не требует предварительной инициализации в ядре и исчезает, когда нет ожидающих.
• Обсуждение подчёркивает, что современные учебники по многопроцессорному программированию обязаны упоминать futex, но «The Art of Multiprocessor Programming» этому не уделяет внимания.
• Улучшения futex2 (Linux ≥5.16) добавили NUMA-поддержку и аналог Windows WaitForMultipleObjects, а io_uring теперь умеет работать с futex.
• Для надёжности при падении потока существуют robust-locks и списки futex, которые ядро автоматически разблокирует.

Запускаю полноценный 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-контейнер.

• О YouTube: О нас, Пресс-центр, Авторское право, Контакты
• Для авторов и бизнеса: Авторы, Реклама, Разработчикам
• Правила и безопасность: Условия, Конфиденциальность, Политика и безопасность, Как работает YouTube
• Дополнительно: Тест новых функций, NFL Sunday Ticket

© 2025 Google LLC

• Участники обсуждают «духовного наследника The Sims», где LLM-агенты создают непредсказуемые, но логичные стратегии и социальную динамику.
• Разработчики подтверждают, что игра началась как продукт и «повернула» в сторону игры; геймплей пока состоит из мини-игр с разными целями.
• Поднимаются вопросы: как удержать LLM от «схода с рельсов», как задать уровень сложности и не перегрузить игру вычислениями.
• Часть игроков хочет полного контроля над промптами и локальных моделей, другие опасаются лишних подписок и «генеративной угарности».
• Побочные темы: баг с ToS, низкий звук в видео, отсутствие Linux-сборки и ностальгия по DXBall.

systemd-харднинг: кратко и по делу

sudo systemd-analyze security показывает «красную» таблицу рисков.
sudo systemd-analyze security имя.service — детально по конкретному юниту.

Колонка Exposure — главный ориентир: чем выше значение, тем больше прав можно отнять.

Как править

1. sudo systemctl edit имя.service создаст override-файл.
2. Параметры пишутся в секции [Service] (или [Container] для quadlet).
3. Сервис не стартует — значит убрал нужное, возвращай.

Часто используемые директивы

Директива	Что делает
NoNewPrivileges=true	запрет setuid/setgid
PrivateTmp=true	изолированный /tmp
ProtectSystem=strict	корень только read-only
ProtectHome=true	/home, /root недоступны
ReadWritePaths=/var/lib/app	белый список для записи
CapabilityBoundingSet=CAP_NET_BIND_SERVICE	только нужные capability
SystemCallFilter=@system-service	разрешённый набор сисколлов
RestrictAddressFamilies=AF_INET AF_INET6	только нужные семейства сокетов
MemoryDenyWriteExecute=true	блок W^X
LockPersonality=true	запрет смены personality()
RestrictRealtime=true	нельзя захватывать realtime-приоритеты
UMask=0077	файлы создаются 600
RemoveIPC=true	чистит SysV IPC при выходе

Пример override

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/myapp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
SystemCallFilter=@system-service
RestrictAddressFamilies=AF_INET AF_INET6
MemoryDenyWriteExecute=true
LockPersonality=true
RestrictRealtime=true
UMask=0077
RemoveIPC=true

Проверь: sudo systemctl daemon-reload && sudo systemctl restart имя.service.

Это не серебряная пуля; подгоняй под каждый сервис и смотри логи.

• Предложена утилита shh, которая по логам strace автоматически подбирает параметры hardening для systemd-сервисов.
• Комментаторы отмечают, что дистрибутивы не включают жёсткие настройки по умолчанию: боятся сломать edge-case’ы и получить поток баг-репортов.
• Обсуждается идея общего репозитория с готовыми «жёсткими» unit-файлами для популярных сервисов.
• Утилита systemd-analyze security и встроенный механизм credentials systemd названы полезными инструментами повышения безопасности.
• Несколько человек поправили: правильное написание — «systemd», а не «SystemD».

С днём 100000-летия, Debian!

Сегодня проекту исполняется 100 000 лет — в двоичной системе, или 0x20 (32) в шестнадцатеричной. С момента основания 16 августа 1993 года Debian вырос из небольшого начинания в один из крупнейших дистрибутивов свободного ПО, охватывающий всё — от встраиваемых устройств до кластеров.

Благодарим всех участников и пользователей за вклад и поддержку. Особая признательность командам FTPMaster, Release, Installer, Images, Press, разработчикам, документаторам, переводчикам и всем, кто помог сделать свежий релиз Trixie возможным. Отдельное спасибо Ансгару за решение проблем с подписью кода.

Празднуем сегодня и продолжаем готовить ещё более мощный Forky.

• Участники поздравляют Debian с «100000-м» (бинарным) днём рождения и вспоминают Иэна Мёрдока.
• Debian хвалят за верность идеалам OSS, надёжность «на века» и удобство для headless-систем.
• Идут шутки о «100000nd birthday» и лингвистике: «th» допустимо, поскольку в бинарной записи последняя цифра 0.
• Кто-то планирует отметить своё 1 000 000-летие, а другой уже выбрал песню на будущий «бинарный» юбилей.

Codemia
Подготовка к систем-дизайн-интервью через практику:
Начать | Блог | Системный дизайн

Юридика
Условия | Конфиденциальность | Контакт

Соцсети
Twitter | LinkedIn

• Обсуждение подтверждает: для HPC, высоконагруженных и чувствительных к задержкам систем NUMA-распределение критично, и ручное pinning процессов/потоков к нужным узлам остаётся основным способом добиться стабильной производительности.
• В публичных облаках (AWS, GCP) NUMA-топология скрыта, VM часто выглядят как однонодовые UMA; полезны lscpu, lstopo, cpu-latency, но настроек управления NUMA почти нет.
• Сообщество делится инструментами: mpibind, sched_ext, DAMON, fake NUMA, идеями эмуляции NUMA даже на Raspberry Pi 5.
• Kubernetes уже умеет NUMA-affinity, но вручную выбирать 64-ядерный инстанс вместо 96-ядерного (чтобы не пересекать сокеты) всё равно приходится самим.
• Крайняя альтернатива — односокетные серверы с NPS=1: «равномерно медленно», но без головной боли.

Claudia – изящный десктоп-клиент для Claude Code.
Лёгкий, быстрый, с минималистичным дизайном.

• Системные требования: macOS 12+, Windows 10+, Linux (AppImage).
• Функции: горячие клавиши, тёмная/светлая темы, авто-обновления, нативные уведомления.
• Безопасность: токен хранится в системном хранилище, шифрование AES-256.
• Установка: скачать dmg/exe/AppImage → установить → авторизоваться через Claude.ai.
• Горячие клавиши:
  • Ctrl+Shift+C – открыть/свернуть окно
  • Ctrl+Enter – отправить запрос
  • Ctrl+L – очистить чат

Проект с открытым кодом: github.com/claudia-app.

• Пользователи считают, что название «Claudia» и визуальный стиль слишком близко к бренду Claude/Anthropic и прогнозируют судебные иски.
• Критика GUI-обёртки: многие ценят Claude Code именно как минималистичный CLI-инструмент и не видят необходимости в «тяжёлом» десктоп-приложении.
• Повторяющиеся жалобы: сайт тормозит, видео на главной слишком быстрое, установка бинарников ломается на Ubuntu 22.04, а вставка картинок в чат зависает.
• Пользователи просят фичи, которых нет: sandbox-агентов, нативной интеграции в VS Code, управления несколькими worktrees, нормального поиска/замены кода.
• Общий вывод: Claudia выглядит как «очередной Twitter-клиент для LLM», и большинство разработчиков возвращается к чистому Claude Code в терминале.

Поисковый индекс Marginalia переписан, чтобы лучше использовать NVMe-накопители.
Основные изменения:

• Объём: после ослабления фильтров и добавления рекламного детектора база выросла с 350 до 800 млн документов; ожидается дальнейший рост при добавлении новых языков.
• Структура: обратный индекс остался «картой терм → список (документ, позиции)», но B-дерево теперь читается в режиме O_DIRECT, минуя кэш страниц.
• Чтение:
  • Буферизованные чтения неэффективны при случайном доступе к файлам, превышающим RAM.
  • Прямые чтения требуют выравнивания по 512/4096 Б, но дают стабильную задержку и не копируют данные лишний раз.
  • В Linux появляется RWF_DONTCACHE, но поддержка пока неполная.

Первая оптимизация — переписать B-дерево под O_DIRECT; дальнейшие шаги ещё описываются.

• 128–256 КБ считаются «классическим» оптимальным размером блока, но в 2024 г. всё чаще замеряют индивидуально: всё зависит от архитектуры I/O.
• Для NVMe при высокой параллельности 4 КБ работает не хуже, если использовать AsyncIO/IO_uring или SPDK и выдавать много одновременных запросов.
• Меньшие блоки экономят чтение, но не избавляют от внутреннего read-amplification SSD; нужно знать минимальный физический размер чтения контроллера.
• Формат LBA (512 B vs 4 КБ+) и опции sysfs (optimal_io_size) влияют на производительность и стоит их проверять.
• В задачах индексного поиска параллельность ограничена, поэтому крупные блоки остаются практичным выбором при отсутствии точных данных о «железе».

• Участники вспоминали старые офис-пакеты и редакторы: Applixware, WordPerfect, Ami Pro, Lotus 1-2-3, iWrite/iDraw/iPaint.
• WordPerfect запускался на Linux через libc5 и патчи (wpunix), а также шёл на HPUX, SCO Unix и даже Data General.
• Всплыли ностальгические моменты: Photoshop на SGI Indy, IE 4 на Solaris, MIT-лаборатории на SPARC/SGI.
• Некоторые считают WordPerfect и Ami Pro более удобными, чем MS Word.
• Apple назван «последней уцелевшей UNIX-компанией», IBM/AIX всё ещё живы в энтерпрайзе.

• 1. «Умный» поиск по всему ПК
  Горячая клавиша → мгновенный поиск по файлам, почте, Teams, облаку и внутри документов. Результаты группируются по типу, поддерживаются фильтры и предпросмотр.

• 2. Контекстные подсказки
  Система подсказывает горячие клавиши, макросы и автозамену прямо в интерфейсе приложения, учитывая текущую задачу.

• 3. Универсальный буфер обмена с историей
  Win+V показывает последние 100 элементов: текст, изображения, файлы. Поддерживает поиск, закрепление и синхронизацию между устройствами.

• 4. «Режим фокуса»
  Одна кнопка блокирует уведомления, прячет панель задач и активирует таймер «Помодоро». Приложения переходят в светлый фоновый режим.

• 5. Автоматические рабочие профили
  Windows сама переключает наборы приложений, VPN, звук и тему в зависимости от календаря или геолокации (дом/офис/поездка).

• 6. Горизонтальные «полки» для окон
  Alt+↑ создаёт «полку» — горизонтальный ряд окон фиксированной высоты. Удобно для мониторов 16:9 и ультрашироких экранов.

• 7. Встроенный OCR и перевод
  Любой текст на экране (видео, PDF, картинка) выделяется прямо мышью и мгновенно копируется или переводится без сторонних сервисов.

• 8. «Песочница» для экспериментов
  Одна команда запускает временную копию Windows с заданным набором ПО. После закрытия всё исчезает, основная система не страдает.

• 9. Умные отчёты о времени
  Еженедельный дашборд показывает, сколько времени ушло на каждое приложение, сколько переключений контекста и где можно сэкономить.

• 10. «Облачное продолжение»
  Закрыл ноутбук → открыл ПК: все окна, вкладки и документы оказались на месте за 5 секунд без ручной синхронизации.

• Пользователи тоскуют по «чистым» ОС вроде Windows 2000/7: быстрым, без рекламы, без назойливых функций.
• Современные версии Windows критикуют за хаотичный UI, лишние клики, принудительные облака, Copilot, Recall и тёмные паттерны.
• Многие предлагают радикальные решения: удалить всё, что добавлено после Win7, или вообще перейти на Linux.
• Популярны скрипты вроде Win11Debloat и «облегчённые» сборки (Tiny11), но Microsoft регулярно ломает такие «фиксы».
• Сторонники Linux признают: для среднего пользователя «безболезненной» альтернативы пока нет, особенно в играх.

OpenBSD быстрее Linux в 10 раз?
Тест Jann Horn: создаём поток, оба потока открывают по 256 сокетов.

Linux

elapsed: 0.017–0.026 s

OpenBSD

ulimit -n 1024
elapsed: 0.002–0.006 s

Машины примерно равны. Подсказка в коде (не в сетевом стеке).
Обычно OpenBSD проигрывает в странных тестах, а тут — наоборот.

• Обсуждение выросло из «патологического» теста, который на Linux показывает замедление из-за роста таблицы файловых дескрипторов и блокировок, а на OpenBSD — нет.
• Участники спорят, что считать «быстрым»: OpenBSD жертвует скоростью ради безопасности, тогда как Linux активно оптимизирует критические пути.
• Для микробенчмарков советуют использовать __rdtsc(), но предупреждают о проблемах синхронизации TSC между ядрами и на ARM.
• Несколько человек отвлеклись на «пасхалку» в статье — плавающие «пушки», стреляющие курсором.
• Общий вывод: измеряйте свою нагрузку на одинаковом железе; универсального «быстрее» не существует.

Ghostty GTK-часть переписана с нуля
Проект завершён: Linux/BSD-версия теперь полностью использует GObject из Zig и проверена Valgrind.

Что изменилось

• Zig-структуры обёрнуты в GObject; память управляется счётчиками ссылок.
• При обновлении конфига старый объект освобождается автоматически, когда исчезают ссылки.
• Появились сигналы, свойства, действия GTK и современные UI-файлы Blueprint.
• Новые виджеты добавляются быстрее (анимированная рамка, вкладки в заголовке и т.д.).

Valgrind Каждый коммит прогонялся под Valgrind.

• Потребовался большой suppression-файл (в основном GTK/драйверы).
• Найдены: утечка и неопределённое обращение в Zig-коде, ошибка WeakRef в GTK, которые иначе вызывали редкие краши.

• Ghostty переписывает GUI на GTK/Zig, столкнувшись с проблемами GObject и управления памятью.
• Участники обсуждают, что GTK навязывает свою ООП-модель и счётчики ссылок, что сложно сочетать с Zig/Rust.
• Некоторые считают GTK не «родной» на Linux и предлагают Vala, Qt или собственный UI.
• Пользователи жалуются на баги прокрутки, копирования, nano и отсутствие поиска.
• Автор признаёт выбор GTK компромиссом ради кроссплатформенности и «родного» вида.

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

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

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».

На 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 и другие приложения игнорируют системные привязки.