Hacker News Digest

• Локальный стек: Ollama (LLM), assistant-ui (веб-интерфейс), Apple container (изолированные ВМ), Playwright (браузер), coderunner (MCP-сервер с Jupyter).
• Цель: чат, запуск кода и доступ в интернет без облаков и утечек данных.
• Проблемы:
  – Модели Ollama пока не поддерживают вызовы инструментов.
  – Создание нативного Mac-приложения провалилось: a0.dev заточен под iOS, Electron + NextJS оказались геморроем.
  – Apple container часто падает с Trap; помогает pkill + перезапуск.
• Решения:
  – Веб-версия assistant-ui через ai-sdk с выпадающим списком моделей (локальных и облачных).
  – Jupyter в изолированной ВМ, доступен по MCP: http://coderunner.local:8222/mcp.
  – Конфиг для Claude Desktop: "coderunner": { "httpUrl": "http://coderunner.local:8222/mcp" }.

• Участники восхищаются локальной, «песочной» архитектурой для приватного AI-воркспейса и инструментом coderunner, но отмечают, что узкие места — это не только софт, но и «железо»: 80B-модели требуют ≥80 ГБ быстрой RAM, что доступно разве что на RTX 4090 или Strix Halo.
• Критичным становится слой знаний: RAG над личными файлами требует вектор-БД, а значит — много диска и оперативки; Docker-обёртка или docker compose up -d просится как минимальный способ разворачивания.
• Пока локальные модели — скорее «увлекательное хобби» (медленно, глючно, нужен тюнинг), чем рабочий инструмент; облачные API (Cerebras, Groq) дают 1000 ток/с, но подрывают приватность.
• Сообщество просит готовый «всё-в-одном» стек: веб-поиск, голосовой режим, image-gen, лёгкий switch «локально ↔ облако» без потери данных.
• Несколько участников делятся своими решениями: Kasm + Ollama, Open WebUI, MLX-электрон-приложение, Synology-NAS-контейнеры, браузерный LLM без установки.

marimo — новый open-source Python-ноутбук, в котором программа представлена графом потока данных. Это снимает главные боли Jupyter: скрытое состояние, невоспроизводимость, невозможность повторного использования и сложную поддержку.

Почему старый формат не подходит

• Воспроизводимость. Исследования 2019–2020 гг. показали: только 4–24 % ноутбуков на GitHub можно перезапустить без ошибок и получить те же результаты. Причина — скрытое состояние: удаление или переупорядочивание ячеек ломает выводы.
• Интерактивность. В Jupyter интерактивен процесс, но не сами данные: выделение точек на графике не возвращает датафрейм.
• Поддержка и переиспользование. Файл .ipynb — это JSON-блоб, не валидный Python-код; сложно версионировать в Git и переиспользовать как модуль или пайплайн.

Как marimo решает задачу

• Каждый ноутбук — корректный Python-скрипт и модуль.
• Граф зависимостей ячеек строится статически; изменение одной ячейки автоматически перезапускает только зависимые.
• Реактивность: обновление переменной мгновенно отражается во всех графиках и виджетах.
• Один файл можно экспортировать как приложение или запускать без ядра Jupyter.

• Пользователи хвалят marimo за реактивное исполнение, «песочницу» uv и лёгкий обмен с коллегами.
• Сторонники Jupyter считают, что «restart kernel & run all» решает проблему воспроизводимости, но критики отвечают: это требует дисциплины и не работает при тяжёлых вычислениях.
• Некоторые видят в ноутбуках лишь инструмент разведки и предлагают после исследования переносить код в обычные .py-файлы.
• Участники сходятся, что метаданные зависимостей и чистые DAG-подобные модели вычислений могли бы улучшить ситуацию.