Hacker News Digest

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 теперь тоже требует сторонних утилит для контроля над ресурсами.

Hister — это личный поисковый движок, который индексирует полное содержимое посещаемых веб-страниц и локальных файлов, позволяя находить информацию через веб-интерфейс, терминал или AI-ассистента, подключённого через MCP. Он работает полностью локально или на вашей инфраструктуре, не требуя телеметрии или облачных сервисов по умолчанию. Установка проста: скачайте бинарник, запустите hister listen, установите расширение для Firefox или Chrome, и после посещения страницы с включённым расширением вы сможете сразу искать по её содержимому.

Ключевые возможности включают полнотекстовый поиск, автоматическую индексацию через браузерное расширение, мощный язык запросов (фразовые поиски, подстановочные знаки, отрицание, фильтры по полям), опциональный семантический поиск через пользовательский эмбеддинг-эндпоинт, импорт истории браузера и локальных директорий, а также поддержку нескольких пользователей на одном сервере. Hister распространяется под лицензией AGPLv3, написан на Go с веб-интерфейсом на Vite и Svelte, и доступен через Homebrew, Docker и Nix. Исходный код открыт, сообщество активное в IRC и Discord, а вкладки принимаются через GitHub с соблюдением правил из CONTRIBUTING.md.

Hister эффективно решает проблему поиска по истории браузера и локальным файлам, особенно для устаревших или удалённых страниц, сохраняя офлайн-превью контента. Интеграция с Obsidian, MCP и AI-ассистентами повышает его полезность для поиска по личным знаниям и голосовыми/текстовыми интерфейсами. Чем больше индекс, тем чаще он помогает находить забытые ссылки. Индексация работает надёжно с браузерной истории, закладок и файловой системы, но требует настройки правил исключения для избежания мусора. Hister работает локально и может быть развернут в tailnet (например, Tailscale) для синхронизации между Windows, macOS и Linux. Пользователи отмечают, что локальные LLM для классификации, резюмирования и извлечения рецептов повышают ценность. Рекомендуется ручное добавление значимых страниц через расширение, а не автоматическая индексация всего. Альтернатива — сохранение страниц в PDF для контролируемого архива. Есть сомнения в безопасности бинарных файлов из непроверенных репозиториев. Синхронизация между устройствами вызывает путаницу из-за отсутствия чёткой документации. Интеграция с Linkwarden и Cherry для поиска по закладкам желаема, но не реализована. Hister превосходит устаревшую функцию Chrome 2008 года за счёт семантического поиска, версий и AI-поддержки. По сравнению с Zotero — лучше для повседневного поиска по истории, тогда как Zotero ориентирован на академическую работу. Индексация работает на уровне URL (включая HN и целевые ссылки), решая проблему индексации только текущей страницы.

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, позволяющую заранее включить её и упростить миграцию конфигураций перед обязательным включением.

Homebrew 6.0.0 — крупный релиз, в котором впервые вводится механизм доверия тапов, позволяющий запускать только проверенные формулы и коки, а остальные отмечать как непроверенные; этот подход снижает риск выполнения произвольного Ruby‑кода из сторонних репозиториев и теперь требует явного согласия перед оценкой любогоtap‑кода. Новый набор команд brew tap, brew trust и brew bundle упрощает управление доверием, включая возможность доверять тапу по его URL и фиксировать списки в удалённом репозитории. Внутренний JSON‑API стал значением по умолчанию, ускоряя обновления brew и сокращая сетевые запросы; прежняя переменная HOMEBREW_USE_INTERNAL_API устарела. На Linux по‑умолчанию включена sandbox‑песочница на основе bubblewrap, выравнивающая её возможности с macOS и укрепляющая правила установки и тестов. По результатам опроса пользователей по умолчанию включён режим ask, требующий подтверждения перед изменениями, а команды brew bundle получили параллельную установку, поддержку npm, krew и winget, а также более гибкую очистку. Эти изменения делают Homebrew быстрее, безопаснее и удобнее как на macOS, так и на Linux, готовясь к будущим версиям, включая macOS 27.

• Благодарность сообществу и разработчикам за многолетнюю поддержку Homebrew.
• Появление новых инструментов (mise, Homebrew‑rs) и обсуждение перехода от Homebrew к альтернативам.
• Вопросы безопасности: механизм доверия taps, необходимость пересмотра подписи и обновления пакетов.
• Призывы к донорству, улучшению документации и поддержке старых версий macOS.

Представлен gem.coop — новый сервер для хранения гемов в экосистеме Ruby, созданный бывшими сопровождающими RubyGems.org. Он предлагает быстрый и простой хостинг, совместимый с Bundler, но оптимизированный для будущего. Все гемы с RubyGems.org доступны в реальном времени, а для использования достаточно заменить источник в Gemfile на https://gem.coop.

Управление проектом организовано по модели Homebrew при поддержке Mike McQuaid, с открытым участием сообщества. Цели — прозрачность, устойчивость и безопасность при общедоступном хостинге. Запуск включает поддержку установки публичных гемов, с планами по дальнейшему улучшению.

• Создана новая альтернативная платформа для пакетов Ruby (gem.coop) из-за конфликта между прежними сопровождающими RubyGems и Ruby Central.
• Обсуждаются технические и организационные аспекты форка: финансирование, необходимость подписи кода, доверие к сопровождающим и проблемы с доступностью из-за домена .coop.
• Часть сообщества поддерживает форк как способ сохранить независимость, другие видят в нём ненужное дробление экосистемы.
• Поднимаются вопросы о мотивах создания форка: является ли это реакцией на политические разногласия или стремлением улучшить техническую инфраструктуру.
• Проводятся параллели с другими инцидентами в open-source (например, переход с Freenode на Libera Chat).

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

Я люблю делиться: пишу блог, веду цифровой сад заметок и выкладываю почти весь код на GitHub. И обожаю читать чужие dotfiles, учиться у них.

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

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.