Hacker News Digest

Плоский текст остаётся одной из самых надёжных технологий хранения данных — он прост, универсален и не зависит от конкретных приложений. Файл .txt можно открыть на любой системе, в любом редакторе, обработать командами вроде grep или sed, и он останется читаемым даже через десятилетия. В отличие от сложных форматов, привязанных к программам, текст не требует специального ПО для доступа — его содержимое видно сразу, даже если вы не понимаете структуру (например, JSON или HTML).

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

Простой текст остаётся самым переносимым форматом, но его использование осложняется разнородными переводами строк, отсутствием встроенных метаданных о кодировке и локали, а также ограничениями Unicode. Для больших наборов данных часто переходят к бинарным решениям, однако ASCII‐текст остаётся надёжным и легко обрабатываемым инструментами и ИИ. ASCII‐текст считается самым надёжным для долгосрочного хранения благодаря однозначной совместимости, устраняющей большинство проблем с глюками в разных системах. Исторически существовали разные окончания строк (CR, LF, CRLF, LFCR), и их смешивание приводит к ошибкам при конкатенации файлов и работе утилит вроде cat. Отсутствие стандартных метаданных о кодировке, переводах строк и локали заставляет программы угадывать параметры файла, что часто приводит к багам. Расширенные атрибуты файловых систем, появившиеся в 1990‐х, частично решают эту проблему. Спор: Одни считают Unicode универсальным решением для многоязычия, но другие указывают, что его многобайтовая структура, переменный порядок байтов и редкие символы делают его менее надёжным по сравнению с ASCII. Совет: Для архивирования небольших табличных наборов данных предпочтительно использовать простые текстовые форматы (CSV, TSV), а для больших бинарных файлов (изображения, научные данные) стоит рассматривать гибридные решения или специализированные бинарные форматы. Совет: При необходимости включать бинарные данные в текстовые файлы удобно применять Base64‐кодирование, хотя это увеличивает объём и не решает проблему семантической структуры. Текст легко обрабатывается командными утилитами (grep, sed) и современными LLM, что усиливает его актуальность в эпоху искусственного интеллекта.

BIGWORDS.PAGE позволяет превратить любой экран в полноэкранный знак, сообщение или таймер через простую ссылку — без аккаунтов, приложений и хранения данных на серверах. Всё содержимое помещается в фрагмент URL (часть после #), который никогда не передаётся на сервер, обеспечивая полную конфиденциальность. Пользователь может создать сообщение вручную через встроенный редактор или сгенерировать ссылку самостоятельно, а затем открыть её на телефоне, планшете, ноутбуке или смарт-TVs — она автоматически подстроится под размер экрана.

Поддерживается разметка Markdown: жирный и курсивный текст, заголовки # и ##, переносы строк. Можно создавать слайды, разделяя содержимое символами || — они будут автоматически меняться по таймеру. Функция {countdown} позволяет вставить обратный отсчёт до указанной даты (&until=) или на заданное время (&timer=). Также доступны генераторы QR-кодов для Wi-Fi, звонков, SMS и email — всё работает локально в браузере, без обращения к сторонним сервисам. Это делает BIGWORDS.PAGE удобным инструментом для встреч в аэропорту, отображения паролей Wi-Fi на стойке регистрации, таймеров на телевизоре или личных напоминаний — всё, что нужно, закодировано в одной ссылке.

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

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

• Многие сравнивают проект с аналогами вроде bigassmessage.com и bigtext.k55.io, подтверждая, что подобные инструменты востребованы и имеют устойчивую нишу в хакерской культуре.

• Совет: Пользователь @pvillano выявил баг в Firefox: scrollWidth включает пробелы в отступы, что ломает адаптивность — предложил исправление через проверку clientWidth вместо scrollWidth.

• Совет: Предложено добавить base64-кодирование для скрытия содержимого в URL, чтобы избежать утечки смысла при делении ссылки — особенно актуально для приватных сообщений.

• Совет: Рекомендовано создать приложение для Google TV / Apple TV, чтобы упростить настройку на телевизорах без ручного ввода URL.

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

• Совет: Пользователь @frankthecobbler запросил возможность скрыть или заменить превью при分享 ссылки в Apple Messages, так как текущий текст слишком нагляден и неэстетичен.

• Использование URL-фрагмента как аргументов для статического веб-приложения (argv) воспринимается как элегантный и чистый архитектурный паттерн, соответствующий принципу DOTADIW.

• Реальные кейсы: использование для предупреждения водителей о проблемах с автомобилем, отображения временных меток для международных игровых встреч и демонстрации спутниковых изображений ураганов на Chromecast.

• Спор: Некоторые пользователи (например, @ShinyLeftPad) считают фразу 'the URL is the app' пустым и навязчивым жаргоном, типичным для LLM, в то время как другие (например, @Zarel, @T0mSIlver) подтверждают её техническую обоснованность.

• Пользователь @paul7986 сообщил об ошибке SSL на Firefox, что указывает на потенциальную проблему с сертификатом или настройками хостинга, требующую внимания разработчика.

• Опыт @mcrowder65 с butts.netlify.app подтверждает, что подобные инструменты находят неожиданные применения в быту и как шутки, что расширяет восприятие их полезности.

I had the idea for BIGWORDS.PAGE when I wanted to display a message on a tablet that I had remote management control over, but no physical access. Configuring it to be a kiosk browser is easy, but how do I get the browser to show my message? So I made the URL be the message. — @SpeakingOfBrad

Перевод: Я придумал BIGWORDS.PAGE, когда хотел отобразить сообщение на планшете, к которому у меня был удалённый доступ, но не было физического. Настроить браузер в режиме киоска легко, но как заставить его показать моё сообщение? Поэтому я сделал сообщение частью URL.

Агентам не нужна память в виде RAG-баз, им нужна документация. Вместо того чтобы извлекать фрагменты разговоров по сходству, агент должен работать с актуальными документами: спецификациями, планами, индексами. Доступ к ним обеспечивает контекст, а не лотерея над векторным хранилищем, где устаревшие или неверные фрагменты могут ввести в заблуждение. Память как RAG решает не ту проблему: она пытается вспомнить прошлое, тогда как люди фиксируют знания в документах и используют их как источник истины.

Автор предлагает систему Operator Memory, где агент перед работой консультирует Markdown-документы в папке internal/, а после — обновляет их, исправляя устаревшее и заполняя пробелы. Это меняет цикл с «промпт → сборка → забвение» на «промпт → консультация → сборка → обновление». Нет векторных баз, эмбеддингов или фоновых демонов — только читаемый, редактируемый и совместный код в виде документов. Такой подход прозрачен, аудируем и соответствует тому, как люди на самом деле работают с знаниями.

Документация эффективнее памяти в виде RAG, но требует структурированных папок, индексов, правил доступа и привязки к коду. Агенты лучше работают с документами в /plans/, /knowledge/, /workbench/, чем с векторными хранилищами, где теряется контекст и данные устаревают. Документы должны быть стабильными и обновляемыми только с разрешения; заметки — эфемерными, чтобы отделить долгосрочное знание от временных мыслей. Индексные файлы (INDEX.md) и привязка документации к коду через ADR, CONTRIBUTING.md, CODING_STANDARDS.md делают знания доступными и проверяемыми. Агенты без доступа к bash используют JSON-память с экспирацией и приоритетами для мониторинга цен и сбоев CI/CD, где структуру определяет LLM. Общий каталог (например, agent-handoff) становится центром коммуникации: агенты обмениваются статусами, решениями и скриншотами. Извлечение семантических утверждений и построение деревьев причин (Whybase) с привязкой к коммитам и коду сохраняет логику решений без потери контекста. Папки как основной механизм хранения (через cd и /resume) — простое и эффективное решение при строгой нумерации и статичной структуре. Поли- и монорепозитории с централизованным хранением кода, документации и прототипов контролируют дрейф контекста и сохраняют историю решений. Агенты лучше работают с инструментами, отображающими доменные типы, чем с универсальными базами, где им приходится гадать о запросах. Документация, извлекаемая из GitHub, Slack, RFC, позволяет ссылаться на реальные источники, повышая точность действий. Сессионная история и простой grep по ней надежнее и дешевле по токенам, чем сложные RAG-системы, которые добавляют шум и стоимость без реальной пользы. Не следует позволять агентам писать в постоянные документы без контроля — это приводит к загрязнению знаний (как в .agents/notes-and-plans/). Линтеры с пояснениями в ошибках (например, для IOSP) дают детерминированную обратную связь, лучше случайных рекомендаций из памяти. Некоторые считают структурированные индексы и 'read-if' условия неумелой заменой умного поиска по тексту и требуют чего-то более интеллектуального, чем grep. Другие утверждают, что агентам нужны и документация, и несколько систем памяти, ссылающихся на документы, и что предложенное решение слишком упрощено.

dbt Charts — это открытый язык на YAML для создания интерактивных дашбордов, разработанный dbt Labs, чтобы соединить свободу кода с управляемостью BI-инструментов в эпоху ИИ-агентов. Он выносит визуализацию из традиционных BI-платформ в код, позволяя агентам генерировать дашборды через чат, сохраняя при этом аудитируемость, версионность и воспроизводимость в Git. SQL остаётся языком для определения данных (WHAT), а YAML описывает их представление (HOW), дополняясь Markdown для текста и Jinja для переменных и макросов — как в dbt.

Язык спроектирован как минимальный, но выразительный набор элементов: переменные для UI-фильтров, именованные запросы и декларативные описания графиков. Пример показывает, как одна переменная, один SQL-запрос и один блок графика формируют полноценный дашборд. Платформа поддерживает conversational analytics — агент с разрешенным только-чтением доступом к warehouse может строить, настраивать и сохранять дашборды через диалог, а затем пользователь может кликнуть, чтобы уточнить детали. Все изменения — будь то из чата, визуального редактора или кода — сохраняются в одном YAML-файле в репозитории, обеспечивая единый источник истины и устраняя необходимость в скрытых стеках данных.

dbt Charts распространяется под лицензией Apache 2.0, работает локально без аккаунта и интегрируется через uv tool install dbt-charts. Бета-версия доступна на GitHub, с документацией, хостингом и сообществом в Slack. Проект пре-1.0, но обратная совместимость обеспечивается миграцией при изменении грамматики. Цель — предоставить открытый слой визуализации, которого не хватало современному стеку данных, чтобы ИИ-агенты могли создавать не просто код, а управляемые, совместные и продуктивные аналитические артефакты.

dbt Charts улучшает аудитируемость и воспроизводимость BI-визуализаций, делая их кодом в Git, что соответствует тренду «unbundling BI». Однако вызывает сомнения выбор YAML как основы DSL: он не поддерживает условные конструкции и привязку переменных, что усложняет шаблоны. Критики отмечают, что продукт не решает ключевые аспекты BI — управление доступом, семантические слои и интерактивность, а лишь отображает сырые SQL-запросы. Некоторые считают, что AI-агенты могут генерировать SVG/HTML-чарты без библиотек, что достаточно для 80% случаев, делая новый формат избыточным. Сравнивают с Malloy, Publisher, VACP, Flint-Chart, Observable Framework и Vega-Lite, где используются более гибкие подходы (Markdown/JS), а также с DaC от Bruin Data как потенциальным конкурентом. Утверждается, что YAML-спецификации напоминают дампы внутренних структур Superset и не предлагают настоящего стандарта. При этом dbt Charts полезен для быстрой генерации метрик в Slack/Teams и интеграции в инструменты генерации приложений, где требуется согласованность стилей. Предлагается использовать его как структурированный формат для внутренних отчётов.

IDEmacs представляет собой набор конфигураций для Emacs, созданный для упрощения входа в этот мощный редактор через имитацию интерфейса популярных IDE. Проект ориентирован на трех основных групп пользователей: программистов, переходящих с других IDE; начинающих Common Lisp и Scheme разработчиков, которым нужна функциональность Emacs без сложной настройки; а также непрограммистов, ищущих полнофункциональный редактор для Org, Markdown или LaTeX.

Ключевая особенность IDEmacs - это сочетание традиционного для Emacs управления с клавиатуры и поддержки GUI с мышью. В отличие от большинства стартовых комплектов для Emacs, здесь не скрываются графические элементы интерфейса, что значительно снижает порог входа для новичков. Проект позиционируется как временное решение ("заплатка") для текущей ситуации, когда Emacs с Sly/Geiser остается лучшей средой разработки для Lisp/Scheme, несмотря на его сложность для начинающих.

• Пользователи спорят о модернизации Emacs: одни хотят сохранить ядро, но обновить UI (giancarlostoro), другие считают устаревший интерфейс фичей (raincole), третьи критикуют производительность (koiueo).
• Альтернативы Emacs обсуждаются активно: VS Code с плагинами (ruguo), OniVim (tiffanyh), Neovim с distant.nvim (pca006132), а также Electron-редакторы с Vim-подобными биндами (trenchpilgrim).
• Удалённая работа через SSH/TRAMP в Emacs возможна (brendyn, v9v), но имеет проблемы с задержками, в отличие от VS Code Remote (pca006132, blubber).
• Клавиатурные комбинации Emacs (C-x, C-c и др.) вызывают поляризацию мнений: одни считают их устаревшими (tom_), другие — неотъемлемой частью (ssivark).
• Сообщество Emacs сопротивляется радикальным изменениям UI, предпочитая кастомизацию через "стартовые пакеты" (ssivark), хотя часть видит в этом контркультурное противодействие прогрессу (stackghost).

Spec-Driven Development (SDD) возрождает подход Waterfall с подробной документацией перед кодированием. Хотя он обещает структуру для ИИ-программирования, рискует погребать гибкость под слоями Markdown. Инструменты вроде Spec-Kit, Kiro и Tessl генерируют спецификации в виде Markdown-файлов, где даже простая функция может требовать 8 файлов и 1300 строк текста.

Процесс SDD создает цепочку документов: от первоначального запроса через спецификации к плану реализации и списку задач. Эти документы затем передаются кодирующему агенту (Claude Code, Cursor, Copilot), который должен написать качественный код. Однако автор сомневается, что такой формальный подход лучше подходит для современной разработки, предлагая вместо этого более итеративный подход с использованием естественного языка.

• Спор вокруг Spec-Driven Development (SDD) в контексте LLM: одни считают, что спецификация — это лишь «точка входа» для модели, другие же видят в ней водопадную модель разработки.
• Сторонники SDD подчеркивают, что спецификация позволяет избежать «vibe-coding» и снижает количество багов, а критики указывают на то, что писать спецификации сложнее, чем код, и что она не покрывает итеративную разработку.
• Обсуждение затронуло TDD и Event-B как смежные практики, а также подняло вопрос о том, как именно спецификация должна выглядеть: как полноценный документ или как краткий конспект.

Автор Heather Burns рассказывает о необходимости "de-Appling" в Великобритании после решения Apple отключить Advanced Data Protection (ADP) из-за требований законодательства по Investigatory Powers Act. Пользователи, уже включившие ADP, должны будут вручную отключить его, иначе потеряют доступ к iCloud. Это затронет 10 категорий данных: iCloud Backup, Drive, Photos, Notes, Reminders, Safari Bookmarks, Siri Shortcuts, Voice Memos, Wallet Passes и Freeform, которые потеряют end-to-end шифрование. Остальные 15 категорий и коммуникационные сервисы вроде iMessage останутся зашифрованными по умолчанию.

Для тех, кому критично шифрование, автор рекомендует срочно перенести эти данные из iCloud. Предлагает использовать сервисы с end-to-end шифрованием, такие как Proton, Standard Notes, Obsidian или Joplin, и избегать миграции к другим крупным технологическим компаниям. Для заметок советует приложение Exporter для преобразования в markdown. Автор подчеркивает, что это часть более широкой тенденции к уходу от американских технологических платформ.

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

Пользователь на форуме задаётся вопросом: зачем нужна разработка в сторону «агентных» ИИ-систем, если текущие модели с трудом выполняют даже простые инструкции. Он привёл пример, когда GPT-5 и Gemini Pro не смогли корректно модифицировать даже одну функцию на 100 строк кода, и выражает скепсис по поводу того, что такие системы смогут работать с десятками файлов.

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

Второй совет — использовать режим планирования (plan mode) в Cursor, где система сначала анализирует проект, составляет план, а затем выполняет его, что значительно повышает качество результата по сравнению с прямым выполнением без плана.

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

• В 2025 году маркетинг AI-решений стал настолько агрессивным, что бренды внедряются в обсуждения на Reddit, LinkedIn и других публичных форумах, чтобы продвигать свои продукты.
• Основная причина разногласий в сообществе разработчиков — это то, что LLM не справляются с задачами, которые не являются тривиальными, и при этом вендоры продолжают их продвигать как будто они могут решить всё.
• Участники обсуждения отмечают, что вместо того, чтобы улучшать модели и инструменты, компании вместо этого сосредоточены на создании и продвижении курсов и "лучших практик" по использованию этих инструментов.
• Некоторые разработчики делятся опытом, что LLM могут быть полезны для рутинных задач, но не для сложных проектов с унаследованным кодом, и что вместо того, чтобы улучшать модели, вендоры продолжают продвигать их как будто они могут решить любую задачу.

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

Ключевые преимущества Typst включают мгновенную работу со шрифтами, интерактивный режим редактирования с автоматической перекомпиляцией и поддержку современных форматов вывода. В отличие от LaTeX, он не требует гигантской установки, проще в освоении и выдаёт понятные ошибки. Хотя замена экосистемы пакетов LaTeX остаётся вызовом, Typst демонстрирует практическую ценность для тех, кто ищет лёгкий и эффективный инструмент для вёрстки.

• Пользователи отмечают значительное преимущество Typst перед LaTeX в скорости компиляции, удобстве синтаксиса и понятности диагностических сообщений.
• Многие перешли на Typst для генерации документов в продакшн-средах (инвойсы, отчёты, книги) благодаря его простоте интеграции с данными (JSON) и программируемости.
• Подчёркивается проблема принятия Typst в научном сообществе из-за доминирования LaTeX-шаблонов журналов и конференций, а также отсутствия полной поддержки инструментов вроде Zotero.
• Некоторые пользователи выражают скептицизм по поводу замены LaTeX для сложных математических формул и опасения по поводу долгосрочного развития и обратной совместимости Typst.
• Typst часто используется как замена Markdown для простых документов и заметок благодаря интуитивному формату и мгновенному предпросмотру.

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

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

• Предложения по применению: для юристов и фрилансеров для учёта рабочего времени, для людей с СДВГ для анализа отвлечений, для автоматизации отчётов на стендапах.
• Обеспокоенность приватностью и безопасностью: отправка скриншотов в облако вызывает опасения по поводу паролей и конфиденциальных данных; предпочтение отдаётся локальным моделям.
• Технические вопросы и предложения: работа с несколькими мониторами, частота записи, интеграция с другими данными (Apple Health), создание API для расширений.
• Юридические и этические аспекты: необходимость согласия на запись в видеозвонках, потенциальное misuse со стороны работодателей для контроля сотрудников.
• Позитивные отзывы: отмечается удобство, качественный UX и возможность использования локальных моделей для конфиденциальности.

TL;DR
Claude Code (CC) радует, потому что максимально прост: один цикл, один контекст, минимум абстракций. Повторить магию можно, если:

1. Один цикл – без мульти-агентов, максимум один «дочерний» процесс.
2. Маленькая модель – для всего, кроме основной задачи.
3. claude.md – живой файл, где агент и пользователь договариваются о стиле и контексте.
4. Теги и примеры – XML, Markdown, куча примеров в промптах.
5. Инструменты
   • Поиск через сам LLM, а не RAG.
   • Высокоуровневые «умные» инструменты (edit, read, todo) вместо низкоуровневых команд.
   • Агент сам ведёт todo-список и отмечает выполненное.
6. Управление стилем – явные просьбы «ЭТО ВАЖНО» и алгоритмы с эвристиками прямо в промпте.

---

1. Цикл

• Одна история сообщений – легко дебажить.
• Подпроцессы – CC может вызвать себя же, но глубина = 1.
• Маленькая модель – подсчёт токенов, сводка diff, украшения UI – всё ей.

---

2. Промпты

• claude.md лежит в корне репо; агент читает и пишет туда же, чтобы «запоминать» договорённости.
• XML-теги (<thinking>, <result>) + Markdown + примеры кода – структурируют вывод и уменьшают бред.

---

3. Инструменты

• LLM-поиск – просим модель выдать до 20 релевантных файлов; быстрее и точнее эмбеддингов.
• Высокий уровень
  • str_replace_editor – редактирует блоки кода, а не строки.
  • todo – агент сам пишет / вычёркивает задачи; видно прогресс.
• Никаких низкоуровневых sed, grep и прочего UNIX-морока.

---

4. Управление

• Тон – «вежливый, лаконичный, не болтает лишнего».
• Капс и «ВАЖНО» – прямо в промпте, работает.
• Алгоритм – пишем в промпте: «если X → сделай Y, иначе спроси», + примеры.

---

Заключение

CC выигрывает за счёт самоограничений: один файл кода, один цикл, простые инструменты. Не усложняйте – дайте модели хороший каркас и позвольте «готовить».

• Критика: пост назван «Что делает Claude Code таким хорошим», но не сравнивает его с другими инструментами, а просто пересказывает документацию.
• Пользователи делятся опытом: кто-то на CC уже построил MVP с платящими клиентами, кто-то сталкивается с регрессиями и «ленью» агента.
• Безопасность: многие боятся давать CLI-инструменту полный доступ к системе, ключам и репозиториям.
• Альтернативы: советуют OpenHands CLI, aider и другие open-source решения; обсуждают, как подключить собственные LLM.
• Тезис «Claude хорош, потому что модель умеет разбивать задачи на шаги и работает в unix-окружении» повторяется как ключевой.

Основы Obsidian
Obsidian строится на базах — папках, где хранятся заметки (*.md). Одна база = одна папка. Внутри можно создавать подпапки, но все они считаются частью этой базы.

Создание

• Новая: File → New Vault → выбрать папку.
• Существующая: Open folder as vault — подключить уже готовую папку с .md.

Место хранения

• Локально (по умолчанию) — файлы на диске.
• Синхронизация — через Obsidian Sync, Git, iCloud, Dropbox и т.д. (файлы остаются вашими).

Одновременная работа
Можно открыть несколько баз одновременно: каждая в отдельной вкладке/окне. Переключение через Ctrl/Cmd+O.

Перенос
Просто скопируйте папку базы — она полностью переносима. Никаких скрытых зависимостей.

• Bases — это официальная табличная надстройка над файлами хранилища: каждая строка = один файл, каждый столбец = его свойство (рейтинг, дедлайн и т.д.).
• Функция только вышла из платного раннего доступа; часть пользователей видит в ней замену плагинам Projects/Dataview, другие считают реализацию сырой.
• Главная претензия: чтобы воспользоваться Bases, приходится дробить контент на множество мелких файлов, что неудобно и грузит файловую систему.
• Тем, кто использует Obsidian как CRM или ведёт кампании D&D, возможность фильтровать и сортировать NPC/контакты уже оказалась полезной.
• Пока нет множественного выбора ячеек, встроенных Kanban-видов и встраивания таблиц в существующие заметки, но API и улучшения обещаны в дорожной карте.