Hacker News Digest

Xiaomi’s новое процессорное ядро Xring O3 демонстрирует резкий сдвиг в архитектуре мобильных чипов: оно превосходит Apple по многопоточной производительности и оснащено 44 МБ кэша — больше, чем у большинства ноутбучных Intel-процессоров. Ядра C1-Ultra имеют 21 порт выполнения, включая шесть для SIMD-операций по 128 бит, что превышает количество портов у современных Intel и AMD. Хотя AMD Zen 5 опережает в обработке 512-битных векторов, для ARM это рекордная ширина SIMD.

Основной тренд — взрывной рост числа исполнительных юнитов и кэша. Процессоры теперь нацелены на параллельную обработку тысяч независимых операций в цикл: сложения, умножения, матричные вычисления через SME2 и SVE2. Это не просто ускорение — это переосмысление вычислений под задачи ИИ и высокопроизводительных вычислений. Большинство транзисторов теперь тратятся не на частоту, а на параллелизм и объём кэша, что делает мобильные чипы конкурентоспособными даже с десктопными решениями.

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

• Спор: Некоторые отмечают, что Xring O3 использует готовое ARM-ядро C1-Ultra, как и MediaTek, и Xiaomi не создавала собственную архитектуру ядра, лишь настраивала интерконнекты и физическую реализацию на TSMC 3nm.

• Спор: Хотя многопоточная производительность выше, однопоточная уступает Apple M5 Max, что ставит под сомнение утверждение о полном превосходстве, особенно в реальных сценариях использования.

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

• Реальные результаты в смартфоне с ограничениями охлаждения и энергопотребления могут быть на 20-30% ниже лабораторных, как это было с MediaTek Dimensity 9500, что делает текущие цифры сомнительными.

• Большой кэш в 44 МБ указывает на то, что узким местом теперь является не вычислительная мощность, а задержка доступа к памяти — это подтверждается несколькими участниками, ссылающимися на архитектурные ограничения.

• Разработчики отмечают, что реальный успех зависит не только от железа, но и от поддержки Linux-ядра, драйверов, инструментов и стабильности экосистемы — всё это пока неизвестно для Xiaomi Xring O3.

• Большинство считают, что Apple остаётся лидером в энергоэффективности и интеграции железа с ПО, и даже при высоких цифрах в бенчмарках Xiaomi не дотягивает до целостности ecosystem Apple.

• Несколько участников подчеркивают, что данные пока основаны на прототипе, а не на финальном продукте в телефоне — это делает любые выводы преждевременными.

• Совет: Стоит ждать независимых тестов и анализа тепловых кривых, а не полагаться на анонсы — как отмечает @StrLght, третьих сторонных данных пока нет, и это критично для оценки.

• Совет: Сравнивать только с Apple не имеет смысла — экосистема iOS/macOS и управление ресурсами важнее, чем цифры в Geekbench, как пишет @bee_rider — переключение ОС не основывается на бенчмарках.

• Совет: Интересно, что производительность GPU близка к M5, но в Android-устройствах она будет сильно ограничена драйверами и термическим лимитом — как отмечает @simjnd, это снижает практическую ценность.

• Спор: Некоторые считают, что Xiaomi не может использовать TSMC и вынуждена использовать китайские литографические процессы с низким выходом годных кристаллов — что объясняет редкость таких чипов, как пишет @hn_submit.

• Китайский прогресс в полупроводниках — это реальность, но его масштабирование и надёжность остаются под вопросом, особенно в контексте безопасности и архитектурных уязвимостей, как в случае Loongson, упомянутых @angry_octet.

• Потребительский опыт с Xiaomi — хороший, особенно по соотношению цены и производительности, как отмечают @rawoke083600 и @otterley, но это не означает технологическое превосходство над Apple.

• Совет: Стоит смотреть на видео с анализом кристалла и кривыми производительности-потребления, как предлагает @picture — там можно увидеть реальные термические характеристики, а не только цифры бенчмарков.

Missing the most important metric: processing power per watt.I have some server CPUs laying around that can also beat Apple CPUs. But putting them in a compact, densely packed, sealed box (aka a phone) would result in a fireball and almost no battery life. — @strictnein

Cobalt — открытая платформа, превращающая Kobo‑ридер в мини‑маркет приложений. После единожды установленного через USB‑кабель каждый новый софт загружается, обновляется и удаляется по Wi‑Fi, а процесс каждого приложения изолирован в отдельном unprivileged‑процессе. Главное преимущество — полная автономность: после перезагрузки возвращается обычный Kobo‑интерфейс, а установленные приложения живут независимо от платформы.

Особенно стоит отметить несколько ярких решений: arXiv просматривает новые предпечати и отображает их полностью на экране; Sudoku и Morse демонстрируют работу UI‑элементов и даже Morse‑код на переднем свете; Gutenbird позволяет читать любые OPDS‑библиотеки, включая Project Gutenberg. Всё это работает на реальном железе — ARM‑бинарники запускаются без root‑доступа, подписи проверяются перед запуском, а установка требует лишь rustup и cargo для сборки. Главное правило: поддерживаются только проверенные модели (на данный момент — Clara BW), и любые изменения можно откатить, перезагрузив устройство.

Тред отражает поляризацию между пользователями, ценящими расширяемость ридеров (Obsidian, Zotero, Libby, KOReader, NickelMenu) и теми, кто настаивает на изоляции от цифрового шума, считая ридер одноканальным инструментом. Критики отмечают, что e-ink не гарантирует фокус — Kindle с браузером и iPad с отключенными уведомлениями демонстрируют это. Технически: двухъядерный процессор критичен для стабильной работы модификаций — он есть в цветных моделях Kobo (Color), но отсутствует в черно-белых (BW). На некоторых устройствах (например, Clara) возможна установка PostmarketOS для Linux-приложений, но это сложнее, чем Cobalt. Пользователи требуют нативную интеграцию с Libby, Zotero, Obsidian и RSS-сервисами, чтобы избежать конвертации в EPUB. Некоторые критикуют использование LLM для описаний и кода как «slop», другие шутят, что ИИ заметил детали, упущенные людьми. Владельцы Kindle выражают зависть к открытости Kobo, полагая, что аналогичная платформа вернула бы их к активному использованию. Для чистого текста черно-белые экраны считаются четче, чем цветные, несмотря на лучшую производительность последних.

RISC-V обещает захватить рынок недорогих микроконтроллеров, но не благодаря продуманному дизайну, а вопреки его недостаткам. Главная проблема — попытка универсального решения: одни требования предъявляются к суперкомпьютерам, другие — к дешёвым ядрам, где важны размер и задержка прерываний, а не производительность вычислений. Автор подчёркивает, что даже если RISC-V победит у 8051, это произойдёт лишь потому, что рынок микроконтроллеров требует простого, дешевого решения, а не потому что ISA идеально подходит.

В статье также критикуются «непрактичные» решения: излишняя сложность спецификации, отсутствие реального опыта разработчиков и «дизайн по комитету», где реальные пользователи остаются в стороне. Автор сравнивает это с ошибками ARM, где указание ядра недостаточно, а поставщикам операционных систем приходится адаптировать образы под бесчисленные платформы. Кроме того, упомянута неудача с векторным расширением — лучше использовать фиксированную ширину SIMD, как в традиционных решениях. Эти пункты подчеркивают, что RISC-V часто упускает из виду реальные инженерные ограничения в пользу теоретических возможностей.

RISC-V не идеален — у него есть недостатки, включая сложность из-за избыточности опций, что может вызывать проблемы с совместимостью и поддержкой. Однако его открытость и гибкость делают его привлекательным для разработчиков. Опыт @jacksons5f подтверждает: RISC-V можно успешно применять в продакшене. Несмотря на критику, экосистема активно развивается, а архитектура доказывает работоспособность в разных средах.

Платформенный процессор, система управления режимом SMM, C6‑DRAM и микрокод процессора можно «разблокировать», перепрограммируя переводы физических адресов DRAM.
skitter-creek-bath-salts вмешивается в нижние уровни иерархии памяти, переписывая регистры контроллера DRAM, чтобы любой виртуальный адрес *p мог указывать в произвольное место физической памяти. При разрушении адресных преобразований исчезают и защита, построенная на них: SEV, SGX, TDX, TrustZone, pKVM, CoVE, SMRAM и даже скрытые регионы PSP и ME становятся доступными.

Эксперимент проведён на процессорах AMD Family 16h, где документация раскрывает регистры переводов, позволяющие менять маппинг без блокировки. Техника универсальна: схожие схемы переплетения, перемешивания и переключения используют все современные контроллеры памяти — от x86 до ARM и RISC‑V. Таким образом, «разблокировка» DRAM открывает путь к новым атакам и исследованиям, показывая, что даже самые защищённые области DRAM можно обойти, если знать, как «перепутать» их адресацию.

Тред обсуждает потенциальные последствия и ограничения эксплуатации подобных атак. Эксперты расходятся во мнениях: одни считают, что атаки могут обходить традиционные механизмы безопасности, другие — что современные системы уже их предотвращают. По опыту @zahlman, атаки возможны лишь при наличии root-доступа. @creshal утверждает, что они позволяют получить доступ к ранее недоступным областям системы. Эксперты советуют ограничивать доступ к таким возможностям только владельцам систем и действовать с осторожностью, учитывая риски для безопасности.

Разработчики Linux интегрировали upstream-поддержку для чипа Qualcomm Snapdragon 8 Elite Gen 5 (кодовое имя SM8750) в основное ядро. Это включает DeviceTree для плат sc8280xp, драйверы для Oryon V2 CPU-ядер (10 ядер: 2x Prime @4.32 ГГц, 6x Performance @3.53 ГГц), GPU Adreno 830, NPU Hexagon и модема X80 5G. Поддержка охватывает PMIC PMX65x, дисплеи, камеры, USB4 и аудио.

Интеграция упрощает портирование Linux на смартфоны и планшеты с этим флагманским SoC 2025 года (TSMC 3 нм), ранее зависевшие от вендорских веток. Ключевые ветки: linux-next и lore.kernel.org, с мержем в 6.15-rc. Qualcomm ускоряет upstreaming, что облегчит разработку нативных дистрибутивов вроде postmarketOS.

• Qualcomm upstreams драйверы Adreno gen5 в LKML, хвалят за прогресс в поддержке ARM Linux, но скепсис из-за прошлых неудач (Tuxedo отказывается, X Elite слабо поддержан).
• Мотивация видят как бизнес-решение после провала Snapdragon X на Windows или PR-стунт, а не искреннюю FOSS-поддержку.
• Интерес к Linux на Snapdragon-ноутбуках, планшетах и телефонах; вопросы по AV1, KVM, WiFi, модемам и периферии.
• Критика закрытого boot-chain, проприетарного hypervisor (Gunyah) и отсутствия документации; призывы к полному открытию.
• Сравнения с Apple Silicon; надежды на устройства вроде Framework или PinePhone с этими чипами.

Новый алгоритм преобразования дней с эпохи 1970-01-01 в дату (год, месяц, день) для 64-бит UNIX-времени работает на 30–40% быстрее предыдущего лидера (Neri-Schneider 2021) и в 2.4 раза быстрее Boost (2012). Он охватывает ±1.89 трлн лет, использует всего 4 умножения (вместо 7+), и оптимизирован для x64/ARM. Бенчмарки на Intel x64 и Apple M4 Pro: ~27 циклов (4M + 15B) против 40 и 51 у предшественников.

Ключевые идеи: подсчёт лет назад (rev = D_SHIFT - days) убирает промежуточные шаги; пропуск day-of-year с year-modulus-bitshift (yrs % 4 * 512 + shift - ypt) вместо деления; Julian Map (cen = (rev * C1) >> 64; jul = rev + cen - cen/4) ускоряет правила високосных 100/400 лет, экономя 2 умножения. Псевдокод: корректировка эпохи, 4 красных умножения (C1/C2/C3/782432), зелёные "бесплатные" на x64 (shift/LEA), выход day/month/year с bump для янв/фев. Код на C++ — open source (BSL-1.0).

• Новый алгоритм конвертации дат в григорианский календарь даёт 30–40% прирост скорости за счёт обратного подсчёта лет и снижения умножений (4 вместо 7+).
• Сравнения с ClickHouse (таблицы поиска), Windows-эпохой (1601) и Unix-временем (без учёта високосных секунд); упоминания исторических календарей с 1 марта как началом года.
• Обсуждение оптимизаций (128-битные числа, constexpr, asm), долгосрочной точности (±1,89 трлн лет) и влияния приливного трения на будущие расчёты.
• Похвалы за подробный write-up, literate programming и open-source C++ код; предложения для наносекунд и микроконтроллеров.

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

• Valve позиционирует SteamOS как альтернативу Windows, используя аппаратные продукты для завоевания игрового рынка.
• Пользователи отмечают потенциал SteamOS на Linux, но подчеркивают проблемы с совместимостью (особенно анти-чит системами) и ограниченную апгрейдабельность/цену устройств.
• Сообщество выражает энтузиазм по поводу "года Linux-десктопа", но сомневается в способности Steam Machines конкурировать с консолями из-за цены и отсутствия эксклюзивов.
• Ключевые аппаратные особенности: ARM-процессор, 16GB DDR5 + 8GB GDDR6, спорное расположение портов USB, отсутствие полной информации о ценах и апгрейдах.

В 2025 году SIMD в Rust продолжает развиваться, предлагая значительный прирост производительности до 64x для операций с u8 на современных процессорах. Основная проблема - фрагментация наборов инструкций: ARM использует обязательный NEON (128 бит), WebAssembly - 128-bit packed SIMD, а x86 имеет сложную иерархию от SSE2 до AVX-512 (512 бит). Для x86 разработчики выбирают между указанием target-cpu (например, x86-64-v3) и использованием function multiversioning для поддержки различных процессоров.

В Rust существует четыре подхода к SIMD: автоматическая векторизация (самый простой), продвинутые итераторы, портируемые абстракции и сырые интринсики. В то время как ARM стандартизировал NEON, а WebAssembly требует компиляции двух бинарных файлов, x86 остается самой сложной платформой из-за множества расширений и необходимости обеспечения обратной совместимости.

• Обсуждение показало, что Rust пока не может предложить стабильный и удобный способ работы с SIMD, в отличие от C# и C++.
• Основная причина — std::simd всё ещё в nightly, а стабильная альтернатива отсутствует.
• Участники также отметили, что даже в ночной ветке API нестабилен и может измениться, что делает его использование в production-окружениях проблематичным.
• Некоторые участники выразили обеспокоенность тем, что отсутствие стабильной SIMD-поддержки может отпугнуть потенциальных пользователей Rust, особенно в областях, где эффективное использование SIMD критично.
• В то же время, другие участники подчеркнули, что Rust всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

Предоставленный текст не содержит содержимого статьи о средстве перевода Rosetta от Apple Developer Documentation. Вместо этого там лишь сообщение о необходимости включить JavaScript для просмотра страницы. Без доступа к фактическому содержанию статьи невозможно создать её точный и ёмкий пересказ в соответствии с требованиями.

• Apple объявляет о прекращении поддержки Rosetta 2 через два года, что фактически означает конец эпохи x86-64 на macOS.
• Разработчики и пользователи обсуждают, что это означает для сторонних приложений, которые не будут пересобраны под ARM, и как это повлияет на Docker, игры и другие инструменты.
• Обсуждается, что Apple могла бы открыть исходники Rosetta 2, чтобы сообщество могло бы продолжать поддержку.
• Участники обсуждают, что это может повлиять на Hackintosh и на то, что macOS может больше не поддерживать x86-64.
• Участники также обсуждают, что это может повлиять на игры, которые не будут пересобраны под ARM.

Новый 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%) обусловлен новым техпроцессом и архитектурными улучшениями, а не увеличением частоты.

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

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

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

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-производителей и драйверов.

Memory Integrity Enforcement (MIE) — пятилетняя разработка Apple, объединяющая возможности собственных чипов и ОС для постоянной защиты памяти без потери производительности. Это крупнейшее обновление безопасности памяти в истории потребительских ОС.

Атаки на iOS ограничены шпионским ПО уровня государств: ценой миллионы долларов, они используют цепочки эксплойтов, основанные на уязвимостях безопасности памяти. Чтобы закрыть этот вектор, Apple:

• создала безопасный язык Swift и переписывает на нём код;
• в iOS 15–17 ввели «типизированные» аллокаторы kalloc_type и xzone malloc, усложняющие эксплуатацию;
• в 2018 году первыми внедрили PAC в A12 для защиты целостности управления;

Оценив стандарт MTE (2019), Apple нашла в нём слабые места и совместно с Arm доработала спецификацию до Enhanced MTE (EMTE, 2022). Ключевые требования Apple: синхронная проверка тегов, постоянная работа и скрытность тегов от злоумышленника. Для этого потребовались глубокие доработки железа, ядра, драйверов и приложений.

• Apple представила Memory Integrity Enforcement (MIE) — систему аппаратно-программной защиты от повреждения памяти, работающую синхронно и по умолчанию на iPhone 17.
• MIE использует расширенное тегирование памяти (EMTE), что резко сокращает число рабочих эксплойт-цепочек: даже при наличии багов восстановить цепь не удалось.
• 4-битные теги (1/16 шанс угадать) защищены частым перевыбором seed и мгновенным крашем при промахе, что делает вероятностные атаки непрактичными.
• Критики отмечают: механизм не спасает от цепочек поставки и усложняет джейлбрейки, превращая устройства в «коммерческие терминалы» без возможности «покопаться внутри».
• Спор об «отсутствии массовых вредоносов» для iPhone: приводятся примеры XcodeGhost, Pegasus и других, но Apple считает их узкими кампаниями, а не эпидемиями.

Блог работает на переработанном Google Pixel 5

Вдохновившись постами в Mastodon о сайтах на ESP32 и Android-солнечных панелях, решил запустить блог с телефона. Успешно: вы это читаете.

Железо

• Google Pixel 5, от Verizon, без разблокировки загрузчика.
• Поддержка USB-OTG и Ethernet-адаптера.
• Питание: 100 Вт солнечная панель + Jackery 160 Вт — сайт полностью автономен.

Софт
Termux + Hugo из репозитория. Пакеты: git, screen, openssh, hugo, dufs (веб-загрузка файлов).
Сервисы: sshd, cronie через sv-enable.

Опыт
Первые сутки — разные версии Hugo и контроль заряда. Сейчас всё стабильно и быстро; внешне не отличить от VPS.

Планы: не трогать, пока не сломается.

• Автор запустил личный блог на старом Google Pixel 5, питая его от солнечной панели и аккумулятора, чтобы продемонстрировать энергоэффективность и повторное использование техники.
• Участники отмечают, что современные ARM-смартфоны потребляют <5 Вт против 50–100 Вт у x86-сервера, что экономит до 800 кВт·ч в год.
• Обсуждаются риски: старые аккумуляторы при 24/7 работе могут «раздуться» и вызвать пожар, поэтому предлагаются варианты безбатарейного питания по USB-PD.
• Вопросы безопасности: Pixel 5 уже не получает обновлений, а Termux-окружение может ломаться из-за несовместимости пакетов.
• Некоторые считают идею интересной, но для статического сайта дешевле и надёжнее использовать GitHub Pages или S3.

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-дистрибутивы ещё десятилетие обеспечат безопасность и работу выброшенного железа.

Почему я перешёл на 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 и приставочную форму.

FFmpeg/asm-lessons — репозиторий с уроками по ассемблеру для FFmpeg.
Цель: научиться писать высокопроизводительные рутины на x86-64, ARM и других архитектурах, ориентированные на мультимедиа-задачи.

Содержание (кратко):

• Уроки: от базовых инструкций до векторных расширений (SSE/AVX, NEON).
• Примеры: реализация IDCT, фильтров, цветового преобразования.
• Тесты: юнит-тесты и бенчмарки для сравнения C vs asm.
• CI: автоматическая проверка на x86-64 и ARM через GitHub Actions.

Как начать:

1. Клонируйте репо.
2. Установите nasm, yasm или llvm-mingw.
3. Соберите пример: make lesson01.

Полезные ссылки:

• Документация FFmpeg
• x86 SIMD
• ARM NEON

• Пользователи восхищаются масштабом FFmpeg и экономией вычислений даже при небольших улучшениях.
• Обсуждаются случаи, когда ручная сборка быстрее intrinsic’ов, и инструменты для поиска «горячих точек».
• Некоторые ждали более глубокой связи с FFmpeg, а не общее введение в ассемблер.
• Поднимаются вопросы портативности (пока только x86-64), необходимости математических подготовок и перегруженности NASM-макросами.
• Большинство соглашается: писать LLVM IR вручную нет смысла, проще использовать inline-assembly или векторные инструкции.

BBC Micro – прародитель ARM-чипов в вашем смартфоне

• ARM-архитектура родилась на BBC Micro; сегодня 60 % мобильных устройств работают на ARM.
• Мой BBC Master – 128 КБ ОЗУ, процессор 65C12, 5¼″ дисковод и трёхкнопочная мышь.
• Почему «BBC»? Британское телевидение BBC в начале 80-х получило госзаказ на компьютеризацию школ.
• В школе был всего один BBC Micro; учитель иногда приносил ZX Spectrum.
• Domesday Project – амбициозный архив 1986 года на лазердиске, но наш класс не дождался результата.
• Преимущества: лучший BASIC, богатые порты расширения, надёжная CMOS-электроника.

• BBC Micro стал прообразом ARM: Acorn, создавшая компьютер, затем спроектировала процессор ARM, как Intel для IBM PC.
• Устройство отличалось мощным BBC BASIC с встроенным ассемблером, что вдохновило множество школьников и хакеров 80-х.
• Участники вспоминают ранние модели, игры вроде Castle Quest, 3D-демо на Archimedes и первые встречи с 32-битным RISC.
• За кулисами стояли Sophie Wilson и другие инженеры Acorn, но её роль часто упускают в рассказах и фильмах.
• Компания породила целую экосистему стартапов, включая ARM, и оставила яркий след в британской ИТ-истории.

Blender теперь нативен на Windows 11 on Arm.
Сборка 4.2.0 Alpha уже доступна для загрузки; финальная версия 4.2 выйдет в июле.

Что это значит

• Нет эмуляции x64 → выше производительность и меньше расхода энергии.
• Поддерживаются все современные граф-функции, включая Cycles, EEVEE, Grease Pencil.
• Работает на Snapdragon X Elite/Plus и других Arm-чипах.

Как получить

1. Скачать Blender 4.2.0 Alpha с официального сайта.
2. Установить и запустить — всё работает из коробки.

Следующий шаг
Разработчики Blender Foundation продолжают оптимизацию; ждём стабильный релиз 4.2 в июле.

• Вокруг Blender на ARM-Windows радость: конец x86-монополии близок.
• Порт был проще благодаря готовым macOS/iOS ARM-версиям, но на Linux-arm64 официальных сборок пока нет.
• Основной тормоз Windows-ARM — отсутствие «жёсткого» перехода: Apple прекратила продажу Intel-Маков, Microsoft и OEM-ы продолжают поддерживать x86.
• Разработчики сторонних библиотек не спешили, многие считали «Windows = x86»; зависимости труднее портировать, чем сам Blender.
• Qualcomm-процессоры пока уступают Apple M-серии, поэтому ARM-Windows-устройств мало, а альтернатив Qualcomm в рознице почти нет.