Hacker News Digest

Mac.apk запускает Android-приложения напрямую на Apple Silicon — без эмулятора, виртуальной машины и ядра Linux. Приложения работают как обычные процессы macOS: рисуются через GPU Mac, исполняются на CPU с нативной скоростью, появляются в Dock, получают собственные окна с кнопкой «назад» рядом с кнопками управления, масштабируются, поворачиваются и переключают светлую и тёмную темы вместе с системой. Ничего не загружает Android в фоне и не интерпретирует инструкции по одной.

Проект в статусе альфа: из 65 протестированных приложений 51 полностью играбельны, 10 работают частично, 4 пока не запускаются. Код под лицензией AGPL-3.0, доступна коммерческая лицензия, сборки подписаны и нотаризованы Apple. Внутри — открытые компоненты (ANGLE, MoltenVK, Capstone, libpng, libvpx, stb_vorbis, Bouncy Castle, JRE на базе OpenJDK с FreeType, HarfBuzz и GLib, ресурсы Android из AOSP); GLib и libintl под LGPL, их исходники приложены к релизам.

Важное предупреждение: у приложений нет песочницы в стиле телефона — APK исполняется как обычный нативный код с правами вашего пользователя macOS и может читать и писать ваши файлы. Устанавливайте только доверенные APK из надёжных источников: за ущерб, утечки данных, вредоносный код и нарушения авторских прав разработчик ответственности не несёт.

Mac.apk не имеет нативных Google‐сервисов, требует MicroG для их работы и не использует песочницу — данные хранятся в /Applications, что вызывает вопросы безопасности. Проект зависит от JVM и не содержит ARM‐бинаров, что ограничивает производительность. Пользователи отмечают нишевые сценарии, например запуск Minecraft Bedrock для кроссплатформенной игры без собственного сервера. Мнения о полезности разнятся: некоторые считают запуск Android‐приложений на Mac интересным, другие предпочитают Bluestacks или iOS‐версии, отмечая низкую реальную потребность. Критики указывают на название и структуру репозитория как признаки низкого качества кода, возможно сгенерированного LLM, и сравнивают проект с устаревшим Android Runtime for Chrome. Некоторые советуют сосредоточиться на PWA вместо нативного Android‐кода для macOS, считая это более перспективным. Рост поддержки Steam‐устройств и упрощение кроссплатформенной разработки могут снизить интерес к запуску Android‐приложений на macOS, а их избыточность в десктопной среде воспринимается как раздражающий фактор.

Исследователи предлагают Minions — распределённый виртуальный GPU-облако, которое объединяет простаивающие графические процессоры устройств на Apple Silicon под управлением macOS для выполнения крупномасштабного машинного обучения. Рост спроса на GPU-ускоренный вывод моделей упирается в ограничения централизованных инфраструктур: высокую стоимость, слабую эластичность и долгие ожидания в очереди. При этом мощные GPU в современных Mac большую часть времени бездействуют. Minions позволяет командам задействовать уже имеющееся оборудование, не закупая новые ускорители, и обеспечивает гибкое выполнение задач вывода, отказоустойчивость и эффективное использование ресурсов.

Практика показывает, что простаивающие macOS-устройства можно превратить в рабочую распределённую платформу для GPU-вывода там, где централизованных ресурсов не хватает. Это особенно актуально на фоне растущей популярности Apple Silicon среди разработчиков и исследователей ИИ: фреймворк MLX уже позволяет эффективно запускать большие языковые модели прямо на Mac, экспериментировать с новыми методами вывода и дообучения и работать с ИИ в приватной среде на собственном железе. MLX поддерживает все системы на Apple Silicon.

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

Minions — технически тривиальное решение, напоминающее SETI@home, без архитектурных инноваций, но потенциально полезное для использования простаивающих мощностей в корпоративной среде. Спор о новизне: @brandonpelfrey и @skhameneh считают архитектуру примитивной (CRUD DB + S3); @yardie отмечает, что аналогичные механизмы давно используются Apple в Final Cut Pro и Xcode CI/CD, хотя @saagarjha не видит связи с распределёнными вычислениями. Энергоэффективность сомнительна: @mcculley указывает, что домашние ПК часто обходятся дороже централизованных дата-центров из-за стоимости электроэнергии и низкой эффективности железа. Идея воспринимается как переизобретение: @cmdrk называет это возвращением к cycle scavenging спустя 40 лет; @pjmlp сравнивает с HPC-кластерами. Виден потенциал в демократизации обучения моделей: @nsagent полагает, что поддержка распределённого обучения (не только вывода) позволит энтузиастам объединять Mac Studio и Mac Mini для федеративного обучения и RL. Существуют аналоги: Salad, Darkbloom, проект exo. Совет: @pm90 предлагает Apple создать независимую цепочку поставок чипов и собственный облачный сервис для захвата рынка аренды ARM-вычислений. Проект может быть полезен компаниям для аналитических задач в нерабочее время на существующем оборудовании (@tom1337).

Модель EmbeddingGemma 2 от Google, созданная как мультимодальный эмбеддер для текста, изображений, аудио и видео в общем пространстве, превращена в систему распознавания речи. Идея в том, что произнесённое слово попадает в векторном пространстве рядом со своим письменным вариантом, поэтому слова можно «вычитывать» напрямую оттуда. Аудиокодер модели остался нетронутым: небольшой «читатель» переносит каждый короткий фрагмент аудио в текстовое пространство, ближайшее из примерно 229 000 английских слов побеждает, а крошечная дополнительная модель расставляет пунктуацию и заглавные буквы. Обучался только «читатель» — менее двух часов на 8 ускорителях H100 на открыто лицензированной английской речи; сама базовая модель никогда не училась на транскрипцию.

Скорость впечатляет: час аудио обрабатывается примерно за 13 секунд на базовом MacBook Air с чипом M3 и 8 ГБ памяти, полностью на устройстве через Neural Engine — это около 288-кратного реального времени. Для сравнения, IBM Granite Speech 5.0 TurboCTC на той же машине даёт примерно 150×, а NVIDIA Parakeet TDT 0.6B v3 на более мощных M4 Pro и M5 Pro — 156× и 335× соответственно, тогда как дообученная Phonon-2 достигает 480×. Пока качество распознавания скромнее: уровень ошибок в словах около 5% против 2–3% у лидирующих речевых моделей, и авторы рассчитывают закрыть разрыв лучше обученным «читателем» в следующей итерации.

Приложение бесплатно для macOS 14+ на Apple Silicon, модели (715 МБ) скачиваются при первом запуске. Можно перетащить аудиофайл или удерживать правый Option, говорить и отпустить, чтобы надиктовать текст в любое приложение; аудио никогда не покидает машину.

Модель EmbeddingGemma 2 работает как сверхбыстрая система распознавания речи с приемлемой точностью (~5 % WER), но пока отстаёт от облачных сервисов. Автор планирует открыть код под Apache License, однако репозиторий пока не найден. Тесты показывают экстремальную скорость: 33‐минутный аудиофайл транскрибируется за 6,75 сек на Mac Mini M4, Parakeet 3 на M1‐MacBook Air — за ~7,5 сек. Для macOS рекомендуется конвертировать модель в CoreML и запускать на Neural Engine, что сокращает время инференса с 60 сек до 10 сек. Точность считается хорошей, но не сравнима с облачными сервисами; WER около 5 % указан без конкретного бенчмарка. Модель ориентирована на английский язык: при транскрибировании португальской речи выдаёт низкокачественный английский текст. Пользователи интересуются поддержкой латинского, корейского, хинди и других языков. Обсуждаются идеи оптимизации: ограничение словаря частыми словами для создания небольшой модели, обучение CTC‐головы поверх аудио‐энкодера Gemma для лучшей точности и скорости, уменьшение размера мультимодальной модели без потери качества, обработка OOV‐слов (текущий метод выбирает ближайшее из ~229 000 английских слов). Сравнительные модели (granite‐speech‐5.0‐470m‐turboctc, Parakeet v3) показывают схожую скорость, подтверждая доступность быстрых локальных STT‐решений. Apple‐модель для локального распознавания речи работает примерно в 3 раза медленнее заявленных показателей, но с похожим уровнем ошибок.

RemoveMacAI — утилита для полного отключения Apple Intelligence на macOS 27 и восстановления занятого ею места на диске. После выключения функций через системные настройки модели ИИ остаются в хранилище, и этот скрипт не только деактивирует функции (Siri, Writing Tools, Genmoji, Image Playground, интеграцию с ChatGPT, суммаризацию в Mail и других приложениях, предиктивный ввод, Spatial Photos и др.), но и удаляет загруженные модели через сервис управления активами Apple, не трогая /System и оставляя SIP включённым. Все изменения обратимы: достаточно выполнить removemacai revert.

Инструмент работает через конфигурационный профиль, который применяет ограничения Apple и перенаправляет запросы на загрузку моделей на локальный закрытый порт, предотвращая их повторную загрузку. Профиль требует ручного одобрения в System Settings. Утилита не делает сетевых запросов и не собирает данные. Доступна через одноразовый установщик (curl ... | bash) или Homebrew (brew install omlahore/tap/removemacai). Поддерживается только на Apple Silicon и macOS 27+. Dictation остаётся рабочим, так как использует отдельные модели. После удаления модели могут ещё отображаться в разделе «Хранилище» до фоновой очистки системой. Spotlight-процесс, именуемый Siri, остаётся активным — это нормально в macOS 27.

Пользователи отмечают рост занимаемого места из‐за Apple Intelligence: модели ИИ занимают 10‐12 ГБ, что критично на SSD 256 ГБ. Отсутствие встроенных средств удаления вызывает опасения по поводу «bloatware» и заставляет искать сторонние решения. Многие ценят открытый исходный код RemoveMacAI, но советуют проверять подписи, provenance‐аттестацию и код перед запуском из‐за рисков безопасности. Некоторые считают удаление ИИ‐моделей бессмысленным, так как они «небольшие и сбалансированные»; другие настаивают, что они занимают ценное место без пользы. Для очистки симуляторов рекомендуется использовать Xcode → Preferences → Locations → Derived Data или вручную удалять ~/Library/Developer/CoreSimulator/Devices, что освобождает сотни гигабайт. Пользователи отмечают, что даже отключённые функции AI продолжают занимать место (пример: 4 ГБ, исчезают и возвращаются), указывая на недостаточную очистку macOS. Ситуация сравнивается с «de‐crufting» в Windows и Android: Apple теперь тоже требует сторонних утилит для контроля над ресурсами.

Homebrew 7.0.0 ускоряет установку и обновление пакетов за счёт оптимизации загрузки и распаковки, а также вводит нативное macOS-приложение с графическим интерфейсом для управления формулами и кегами. Поддержка macOS 10.15 Catalina прекращена — теперь минимальная версия — macOS 11 Big Sur, а Intel-маки переведены в Tier 3: новые бинарные пакеты (bottles) для них больше не собираются, и рекомендуется мигрировать на MacPorts или обновлять систему до Sequoia 15+ для полной совместимости. Apple Silicon Macs остаются на Tier 1 с полной поддержкой и готовыми бинарниками.

В области безопасности добавлены встроенные проверки уязвимостей и база рекомендаций (advisory database), которая сканирует установленные пакеты на известные проблемы при brew upgrade и brew info. Усилено изолирование (sandboxing) при установке и работе с taps — теперь сторонние репозитории работают в более строгом контексте, а установка через setuid-обёртки запрещена: команды должны выполняться от владельца префикса. Для команд CI и нестандартных префиксов улучшена надёжность и прозрачность поведения, а образ ghcr.io/homebrew/ubuntu22.04 удалён — пользователям рекомендовано перейти на ghcr.io/homebrew/brew. Также объявлено, что ветка master в репозитории Homebrew/brew будет заморожена и удалена 1 марта 2027 года — необходимо перейти на main. Проект остаётся полностью волонтёрским и призывает к поддержке через спонсорские платформы. На момент выпуска открытых issues в репозитории нет — впервые с версии 6.0.0.

Обсуждение подтверждает заявленное ускорение Homebrew 7, но выявляет реальные проблемы: прекращённая поддержка Intel‐Mac, требование sudo/root, баги GUI‐приложения и удаление wine, а также подчёркивает новые механизмы sandbox и возможности альтернативных менеджеров вроде Mise.

• Много пользователей отмечают, что установка и обновление пакетов стали заметно быстрее, что подтверждает обещанное ускорение в Homebrew 7.

• Совет: @asadhaider делится алиасом: alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup", позволяющим автоматически поддерживать систему в актуальном состоянии.

• Совет: @AbuAssar указывает, что новое графическое приложение можно установить командой brew install homebrew-app.

• Спор: Пользователи делятся противоположными мнениями: одни хвалят значительное ускорение и новые функции, другие расстраиваются из‐за прекращения поддержки Intel‐Mac и невозможности использовать GUI‐приложение на старом железе.

• Совет: @Sytten и @azuanrb советуют использовать менеджер Mise для единой конфигурации пакетов, отмечая, что он не ломает виртуальные окружения Python и упрощает управление зависимостями.

• Несколько комментариев (например, @mkrishnan, @gdevenyi) подтверждают, что установка Homebrew по‐прежнему требует sudo/root, что остаётся барьером для некоторых пользователей.

• Совет: @simonw раскрывает, что механизм sandbox в Homebrew построен на собственном wrapper‐е sandbox‐exec, что важно учитывать при оценке безопасности.

• Спор: Пользователи @spdustin и @mpweiher сообщают об ошибке GUI‐приложения "Failed to decode Homebrew JSON output", указывая на текущие проблемы стабильности нового интерфейса.

• Много участников отмечают улучшения в безопасности, такие как усиленный sandbox и встроенные проверки уязвимостей, как важные плюсы релиза.

• Совет: @basedpolymer делится опытом: на старом Intel‐MacBook GUI‐приложение не работает, поэтому пришлось вернуться к традиционным методам установки.

• Удаление cask wine вызвало разочарование у пользователей, например @xvilka, подчёркивая, что некоторые популярные пакеты могут исчезать из репозитория.

• Совет: @yougotwill хвалит функцию trusted taps, позволяющую заранее включить её и упростить миграцию конфигураций перед обязательным включением.

Apple представила iPhone 18 Pro и iPhone 18 Pro Max с новой 48 МП Fusion Main камерой, получившей переменную диафрагму и расширенные Pro-контролы в приложении Камера. Это обеспечивает творческий контроль, ранее недоступный в смартфонах, включая точную настройку глубины резкости и улучшенную работу в условиях низкой освещённости. Оба устройства получили более компактный и функциональный Dynamic Island, чип A20 Pro и следующее поколение паровой камеры, обеспечивающее最高 устойчивую производительность в истории iPhone. iPhone 18 Pro Max предлагает рекордный прирост времени работы от батареи благодаря улучшенному Apple Silicon и увеличенной ёмкости аккумулятора.

Смартфоны работают на iOS 27 с интегрированным Apple Intelligence и обновлённым Siri AI, который понимает личный контекст, анализирует содержимое экрана и помогает в реальном времени — от поиска в сообщениях и фото до управления камерой голосом. Функции вроде Spatial Reframing, Extend и улучшенного Clean Up позволяют редактировать фото после съёмки, а Image Playground генерирует фотореалистичные изображения. В Safari функция Notify Me отслеживает изменения на веб-страницах (наличие товара, цены). Конфиденциальность обеспечивается за счёт обработки данных на устройстве и технологии Private Cloud Compute, распространяющей защиту iPhone в облако. Поддержка eSIM только моделей доступна у более 500 операторов по всему миру, включая США, Канаду, Японию и страны Персидского залива.

iPhone 18 Pro не оправдывает ожиданий: функция подписи изображений (Apple Reference Image) легко обходится съемкой AI-изображения, а облачная обработка ставит под сомнение сохранность оригинала — при этом Android уже поддерживает C2PA. Пользователи требуют открытия depth-API, подписи видео, двойного модема, Thunderbolt вместо USB-C, eSIM и спутниковой связи. Заявленные 45–60 часов автономности вызывают скепсис, а качество фото, несмотря на апгрейд аппаратуры, ухудшается из-за агрессивной пост-обработки. Отсутствие данных о RAM и пропускной способности памяти вызывает тревогу. Цена $1199 за переменную диафрагму и 12 ГБ RAM считается завышенной; требуют стилуса, прозрачного производства в США, e-ink заднего экрана, складных форматов и улучшенного AI-ассистента. Многие считают обновление неоправданным — улучшения слишком незначительны для ежегодной замены.

Linux 7.2 принёс значительный прогресс в поддержке Apple Silicon через Asahi Linux, особенно в управлении питанием CPU. Основная проблема — отсутствие EL3 в чипах Apple, что блокирует использование стандарта PSCI для управления состояниями сна ядер. Вместо этого ядро работает в EL2, а m1n1 — кастомный загрузчик — выступает как промежуточное ПО, позволяющее обойти ограничения. Для сохранения энергии используется глубокий WFI, при котором ядро отключает часть компонентов и сохраняет состояние, но это решение не может быть вынесено в основную ветку ядра из-за нарушения архитектурных требований.

На фронтенде достигнут прорыв: AGX (графика) и DCP (дисплей) теперь могут напрямую передавать фреймы без посредников, что критично для производительности и энергоэффективности. Однако KDE’s Kwin пока не поддерживает такой «многопроцессорный» вывод, отключая DMA-BUF, но исправление ожидается в Plasma 6.8. Также обновлены драйверы I2S, SMC и hwmon, исправлены совместимости с macOS 27. Рост команды и новые разработки — включая поддержку M4 и AVD — стали возможны благодаря спонсорам, чья поддержка позволяет преодолевать сложнейшие аппаратные барьеры.

Тред уходит от техотчёта в контекст вокруг Asahi: усталость от macOS, практичность реверс-инжиниринга Apple, споры о шорткатах и сомнения в долгосрочной нужности проекта. Содержательных технических добавлений мало. Asahi как запасной вариант: @stiray, @wishfish, @tiahura и @a96 сходятся на том, что особенности macOS (шорткаты, невозможность починить систему) раздражают и нужна альтернатива. Спор о шорткатах: @strbean считает Cmd-C/V единственным разумным стандартом. @stiray, @brewmarche и @a96 возражают — нестандартные биндинги macOS создают постоянную боль для мульти-OS пользователей. @wishfish предлагает ремап Command на Control в системных настройках — работает без сторонних инструментов вроде Karabiner. Спор о долгосрочной нужности Asahi: @dgunay и @throwa356262 считают, что ресурсы лучше вложить в Strix Halo, NPU и старые Qualcomm SoC. @raybb и @MBCook возражают аргументом об ewaste и уникальности железной проблемы. @maccard ставит под вопрос тезис о том, что Panther Lake сравняется с Apple Silicon — на рынке нет ноутбука с железом, эквивалентным MacBook Pro. @xoa оспаривает тезис о невозможности общего дискового пространства: ZFS-раздел или iSCSI для сетевого Home работают на M4 mini без нативного Linux на железе. По ARM и WFI на Apple Silicon: @ksec удивлён нарушением духа спеки, @j16sdiz уточняет, что поведение допустимо при наличии архитектурной лицензии Apple, а проблемный регистр доступен только из ядра. @ZiiS просит добавлять в прогресс-репорты Asahi строку о масштабе известных открытых багов — DP Alt Mode уже год работает без упоминания. @dreamcompiler выбрал гибридный путь: Linux в VM на Apple Silicon ради времени работы от батареи и общего доступа к данным с macOS. @owaislone и @LoganDark считают главным нерешённым вызовом Asahi power management и время работы от батареи — Linux проигрывает из-за отсутствия проприетарных драйверов. @djxfade возражает: для Apple нет бизнес-смысла делать Linux first-class, потому что продукт — это связка hardware+software. @djfergus добавляет, что усилия Apple по безопасности объясняют нежелание поддерживать альтернативные ОС. @megous предупреждает: VA-API плохо ложится на v4l2-request — VA-API пересчитывает часть данных из битстрима, а v4l2-request ожидает оригинальный распарсенный битстрим; ссылается на свой форк libva-v4l2-request.

Apple анонсировала новый Mac Studio с процессорами M5 Max и M5 Ultra, позиционируя его как мощный настольный компьютер для ИИ-задач и экстремальных профессиональных рабочих процессов. M5 Max предлагает 18-ядерный CPU, до 40-ядерный GPU с нейроакселераторами в каждом ядре и до 128 ГБ унифицированной памяти, обеспечивая до 4,3× ускорение ИИ-производительности и до 1,8× рост графической мощности по сравнению с предыдущим поколением. M5 Ultra удваивает эти показатели: 36-ядерный CPU, до 80-ядерный GPU и впечатляющие 512 ГБ унифицированной памяти, что позволяет запускать огромные языковые модели полностью на устройстве. Оба варианта поддерживают пропускную способность памяти до 614 ГБ/с, Wi-Fi 7, Bluetooth 6 и Thunderbolt 5, который также позволяет объединять несколько Mac Studio в кластер для распределённого ИИ-вывода с до 3× ускорением по сравнению с одиночной системой.

Mac Studio позируется как полноценная платформа для разработки ИИ благодаря новым фреймворкам Core AI и MLX, оптимизированным под Apple Silicon, которые совместно с Xcode и macOS 27 обеспечивают полный цикл работы: от экспериментов и обучения моделей до их локального развёртывания. Поддержка Apple Intelligence и Siri AI дополняет экосистему, делая систему привлекательной для разработчиков, исследователей, данных учётов и креативных профессионалов. Устройство доступно для предзаказа с 25 августа 2026 года, а начало продаж — 22 сентября. Thunderbolt 5 также расширяет возможности подключения внешних накопителей, PCIe-шасси и хабов для самых интенсивных нагрузок.

Обсуждение дополняет анонс Apple, подчеркивая, что M5 Ultra — это мощный, но чрезвычайно дорогой инструмент для локального ИИ, который подходит лишь узкому кругу профессионалов, а не массовому рынку, и его цена не оправдана для большинства пользователей, особенно при наличии более доступных облачных альтернатив.

• Совет: Пользователь @joshstrange предлагает заменить закрепленный MBP на Mac Studio с Neo для редких удаленных задач, так как это экономит деньги и упрощает инфраструктуру.

• Спор: @kristianp оспаривает утверждение Apple о возможности использования Mac Studio как сервера LLM для офиса, утверждая, что скорость токенов слишком низка для бизнес-применений, и лучше купить несколько GPU NVIDIA.

• Совет: @alberth указывает, что 512 ГБ оперативной памяти для M5 Ultra появится только в октябре, а базовая версия M6 ограничена 32 ГБ, что подтверждает ограничения в текущей конфигурации.

• Совет: @tristor отмечает, что 512 ГБ — это лишь порог «достаточно», а для надежного запуска моделей >1T параметров с 4-битным квантованием требуется 1 ТБ памяти, что Apple не предлагает.

• Совет: @gizajob и @nythroaway048 отмечают отсутствие 1 ТБ опции как стратегическое ограничение Apple, несмотря на спрос со стороны финансово обеспеченных пользователей и исследователей.

• Совет: @vadansky спрашивает, можно ли ожидать производительности Opus на M5 Max с 256 ГБ, что указывает на нехватку прямых сравнений производительности моделей LLM на этих чипах.

• Совет: @swader999 подчеркивает, что облачные решения стоят дешевле ежемесячной аренды Mac Studio, что делает локальный ИИ на этом устройстве экономически нецелесообразным для многих.

• Совет: @mythz считает, что цена 164 ГБ оперативной памяти в $4000 — это «апокалипсис памяти», и предлагает перейти на M6 Mac Mini как временное решение, пока цены не упадут.

• Совет: @nico_h утверждает, что текущие цены на память неустойчивы и неоправданы для корпоративных клиентов, так как стоимость токена ниже реальной стоимости его генерации.

• Совет: @ChildOfChaos советует ждать два года, чтобы цены снизились или появилась более доступная альтернатива, так как текущие цены слишком высоки.

• Совет: @prometheus1992 предупреждает, что новые Mac Studio и Mac Mini будут в дефиците как минимум шесть месяцев после 22 сентября, что влияет на доступность.

• Совет: @gigatexal шутливо сравнивает стоимость M5 Ultra с BMW 3 серии, подчеркивая, что устройство — это роскошь, а не необходимость для большинства.

• Совет: @jdeaton отмечает, что Mac Studio не поддерживает Linux, что исключает его для разработчиков, зависящих от Linux-экосистемы.

• Совет: @OneWhereWhy выражает опасения по поводу тепловыделения PCIe Gen 6 SSD в настольных ПК, так как ранее такие диски использовались только в корпоративных системах с лучшим охлаждением.

• Совет: @drnick1 предлагает, чтобы Apple вернулась к традиционным ATX-башням с расширяемыми слотами, чтобы улучшить апгрейд, охлаждение и гибкость, а не делать компактные, неремонтопригодные устройства.

По сообщению 9to5Mac, Тим Кук может покинуть пост CEO Apple уже в следующем году. Эта новость вызвала ажиотаж среди инвесторов и технологического сообщества, учитывая, что Кук возглавляет компанию с 2011 года после Стива Джобса. Хотя официального подтверждения от Apple пока не поступало, источники указывают на возможный переход руководства в ближайшее время.

Инвесторы密切关注ают развитие событий, так как смена руководства может повлиять на стратегию развития компании, особенно в условиях растущей конкуренции на рынке технологий. Кук, занимающий пост CEO более 12 лет, руководил Apple через несколько значительных продуктовых запусков и перехода на собственные процессоры Apple Silicon.

• Критика Тима Кука за отсутствие видения и превращение Apple в компанию, ориентированную исключительно на максимизацию стоимости акций.
• Признание заслуг Кука в масштабировании компании и создании успешных продуктов (M-чипы, Vision Pro, AirPods, Apple Watch).
• Обсуждение преемников, с Джоном Тернусом как основным кандидатом на пост CEO.
• Ностальгия по Стиву Джобсу и его философии дизайна, противопоставляемой текущему руководству.
• Тревога о будущем Apple в эпоху ИИ и необходимости нового лидера с сильным видением.

Пять лет после выхода первых Mac с чипами M1 показали, что предсказуемые обновления — это именно то, чего мы хотели. Автор статьи цитирует Джона Грубера, который в 2020 году отмечал, как M1 сломал компромисс между производительностью, нагревом и временем работы от батареи. Несмотря на это, некоторые называют M5 «скучным incremental-обновлением», что, по мнению автора, как раз и является целью.

В эпоху PowerPC и Intel Mac иногда годами не получали значительных апдейтов, а проблемы с перегревом и неудачные решения вроде клавиатуры-бабочки были обычным делом. Теперь, когда Apple контролирует собственную silicon-архитектуру, компания может регулярно выпускать чипы с последовательным улучшением производительности и эффективности. Графики Geekbench показывают значительный прирост производительности CPU и GPU от M1 до M5, и для большинства пользователей, не меняющих компьютеры каждый год, каждое обновление будет ощутимым.

Это и есть успех Apple silicon — не революция, а эволюция, которая обеспечивает стабильный прогресс. Назвать такие достижения «скучными» — значит упускать суть и игнорировать то, что мы сами и требовали от Apple после перехода с Intel.

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

Команда Asahi Linux продолжает работу над поддержкой чипов Apple M3, хотя на данный момент базовая функциональность позволяет только загружать систему до мигающего курсора. Разработчики активно портируют загрузчик m1n1 на язык Rust, что повысит безопасность и поддерживаемость критически важного компонента. Параллельно ведется работа над патчами ядра Linux для версий 6.17 и 6.18, где уже добавлены Device Trees для устройств Apple M2 Pro/Max/Ultra.

Успехи также отмечены в игровой сфере — Wine теперь работает вне muvm, а поддержка графики продолжает совершенствоваться. Несмотря на прогресс с M1 и M2, чипы M3, M4 и недавно анонсированный M5 все еще находятся в стадии обратной разработки. Как отмечают разработчики: "Базовая поддержка M3 существует давно, но она ограничивается возможностью загрузки до мигающего курсора, что полезно только для низкоуровневого реверс-инжиниринга".

• Пользователи обсуждают, что владельцы Mac на M1-M4 чипах по-прежнему не могут полноценно использовать Linux на своих машинах, и это вызывает тревогу, особенно учитывая, что Apple не проявляет особого интереса к поддержке Linux на своих устройствах.
• Участники обсуждения отмечают, что даже несмотря на это, сама по себе поддержка Asahi Linux остается важной, так как она позволяет продлить жизнь этих устройств, когда Apple прекратит поддержку macOS.
• Некоторые участники подчеркивают, что ситуация с Linux на Apple Silicon выглядит как бесконечная борьба, и что это может быть неразрешимой проблемой, если Apple не изменит свою политику.
• Также обсуждается, что в то время как Apple продолжает выпускать новые чипы, Asahi Linux может не успевать за ними, что делает невозможным поддерживать актуальные версии ядра и драйверов.
• Наконец, участники обсуждения отмечают, что существует альтернатива в виде ноутбуков от других производителей, которые лучше подходят для Linux, но они не такие же качественные, как MacBook, что делает выбор сложным для тех, кто предпочитает Linux, но привык к премиальному качеству MacBook.

Плато обучения в модели PyTorch оказалось не ошибкой гиперпараметров, а багом в бэкенде фреймворка. Автор провёл детективное расследование, которое научило его больше о PyTorch, чем годы использования. Проблема заключалась в ядре MPS для Apple Silicon, где операции addcmul_ и addcdiv_ при работе с ненепрерывными тензорами молча записывали результаты во временный буфер вместо самого тензора.

Из-за инициализации весов энкодера как транспонированных декодера они получали ненепрерывную память, которая наследовалась состояниями оптимизатора Adam. Это приводило к тому, что exp_avg_sq.addcmul_() не обновлялся, оставаясь нулевым, что полностью останавливало обновление параметров. Исправить проблему можно, сделав веса непрерывными при инициализации, обновив PyTorch до версии ≥2.4 или перейдя на macOS 15+.

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

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