В GitHub создан новый инструмент для управления задачами «Firm», который предназначен для разработчиков и технических специалистов. Он использует текстовый интерфейс для управления проектами, задачами и багами, интегрируясь с Git. Основная идея в том, чтобы обеспечить прозрачность и избежать навязывания конкретных инструментов, сохраняя при этом простоту и эффективность.

Инструмент позволяет создавать и отслеживать задачи прямо из командной строки, что ускоряет workflow. Он также поддерживает интеграцию с другими инструментами, такими как GitHub Issues, делая его мощным дополнением для разработчиков, уже использующих Git.

Ключевая особенность — минималистичный дизайн, который не мешает основной работе, и возможность настройки под конкретные нужды команды. Это пример того, как open-source инструменты могут улучшить продуктивность без добавления излишней сложности.

• Пользователи обсуждают CLI-ориентированные инструменты для управления бизнесом, но признают, что для широкого распространения нужен GUI.
• Обсуждается, что текстовые форматы (JSON, YAML) могут быть более удобны для LLM и человека, но вызывают проблемы с масштабируемостью и обработкой больших объемов данных.
• Участники отмечают, что подобные инструменты могут быть полезны для малого бизнеса и как личный инструмент разработчика, но сомневаются в их применимости для более широкого круга пользователей без GUI.
• Поднимается вопрос о том, что такие инструменты могут быть полезны для управления собственным бизнесом, но также отмечается, что для этого может быть достаточно уже существующих инструментов.
• Участники также обсуждают, что вместо изобретения нового формата данных, возможно, стоит использовать существующие форматы, такие как JSON или CSV, что может упростить интеграцию с другими инструментами.

Kaitai Struct — декларативный язык для описания и разбора бинарных форматов, позволяющий определить структуру данных один раз, а затем использовать это описание в различных языках программирования. Поддерживается 12 языков, включая C++, Java, Python, JavaScript и Rust, что делает его универсальным инструментом для работы с бинарными файлами и сетевыми протоколами. Проект бесплатный и открытый, включает компилятор, веб-IDE, визуизатор и обширную библиотеку популярных форматов.

Система работает через описание формата в файле .ksy, который компилируется в исходный код выбранного языка. Например, простое описание заголовка GIF позволяет получить доступ к таким полям, как ширина и высота изображения через удобный API. Такой подход устраняет необходимость в написании повторяющегося, подверженного ошибкам кода для разбора бинарных структур, экономя время и упрощая отладку.

• Kaitai Struct — декларативный язык описания бинарных форматов, который генерирует код на разных языках.
• Пользователи отмечают, что он удобен как для работы, так и для хобби-RE, но жалуются на отсутствие поддержки записи и громоздкий YAML.
• Появилась экспериментальная поддержка сериализации в Python и Java, но она пока не покрывает все типы полей и требует ручной работы.
• Сравнение с Wuffs и Construct показывает, что Kaitai фокусируется на описании форматов, тогда как Wuffs — на безопасном коде, а Construct — на удобстве использования.
• Сообщество обсуждает, что нехватка поддержки других языков (Rust, Zig) и отсутствие поддержки полного цикла чтение-изменение-запись делает Kaitai менее универсальным, чем можно было бы.

В статье обсуждается, что главная проблема конфигурационных файлов — не синтаксис, а отсутствие абстракций. Хотя многие ругают YAML за сложность, реальная проблема в том, что даже простые форматы вроде JSON не решают проблему дублирования и ошибок вроде опечаток в числовых константах.

Автор показывает на примере: если нужно описать несколько однотипных ресурсов (в примере — cloud-бакетов для бэкапов), то даже в JSON или YAML придётся дублировать код, что ведёт к ошибкам. Например, в одном месте указали 2592000 секунд (30 дней), а в другом — 259200 (пропустили ноль), и из-за этого данные удаляются через 3 дня, а не 30.

Решение — использовать язык конфигурации, который поддерживает абстракции, как в языках программирования. Например, RCL позволяет использовать переменные, циклы и вычисления, что исключает ошибки из-за опечаток и дублирования. Так, вместо шести повторяющихся блоков конфигурации можно написать один цикл, который сгенерирует их все, гарантируя, что все значения согласованы.

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

• Обсуждение в основном вращается вокруг того, что конфигурационные языки (YAML, JSON, TOML и т.д.) не масштабируются и не имеют абстракций, что приводит к необходимости встраивать в них полноценные языки программирования, что в свою очередь создает проблемы безопасности и предсказуемости.
• Участники обсуждения подчеркивают, что вместо того, чтобы изобретать новые конфигурационные языки, следует использовать существующие общеязыковые инструменты (Python, Lisp и т.д.) для конфигурации как код, что позволит избежать проблем с безопасностью и сложностью.
• Некоторые участники также упоминают, что проблема не в синтаксисе или структуре данных, а в отсутствии стандартного языкового сервера для конфигурационных файлов, что делает невозможным автодополнение и переход к определению.
• Также поднимается вопрос о том, что если конфигурационный язык предоставляет возможность встраивать код, то это может быть использовано для вредоносных целей, и вопрос о том, как обеспечить безопасность таких файлов, становится критически важным.
• В конце концов, обсуждение сходится на том, что вместо того, чтобы продолжать изобретать новые конфигурационные языки, следует использовать существующие языки программирования и инструменты, которые уже решают эти проблемы.

MAML — это минималистичный формат для данных, который сохраняет читаемость для человека и при этом остаётся простым для машинной обработки. Он сочетает лучшее из JSON, дополняя его комментариями, многострочными строками и необязательными запятыми и кавычками.

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

Atuin Desktop — это инструмент, который объединяет документацию и исполняемые команды в едином пространстве, похожем на документ, но работающем как терминал. Он позволяет создавать и запускать сценарии, запросы к базам данных, HTTP-запросы и даже встраивать графики Prometheus, делая рабочие процессы повторяемыми, совместными и надёжными. Это решает проблему устаревшей документации и разрозненных знаний, которые часто хранятся лишь в памяти или истории команд.

Инструмент теперь полностью открыт под лицензией Apache 2.0 и включает интеграции с Kubernetes, MySQL, Git-совместимые рабочие пространства и возможности совместной работы в реальном времени. Планы развития включают удалённое выполнение, аудит, расширенные блоки и улучшенную интеграцию с облачными провайдерами.

• Пользователи отмечают полезность инструмента для документирования и выполнения команд, особенно для редких или сложных задач администрирования.
• Обсуждаются аналогичные подходы и инструменты: bash-скрипты, Jupyter Notebooks, org-mode в Emacs, runme.dev, speedrun.cc и Warp Notebooks.
• Поднимаются вопросы о безопасности, включая риски выполнения деструктивных команд из истории и необходимость подтверждения.
• Обсуждаются технические аспекты: поддержка shellcheck, формат файлов (YAML), работа с Git, удаленное и параллельное выполнение.
• Авторы отвечают на вопросы, подчеркивая гибкость подхода, планы по развитию и открытость к обратной связи.

YAML позиционируется как удобный для человека формат данных, но на деле оказывается чрезвычайно сложным и полным скрытых ловушек. Его спецификация занимает 10 глав с многоуровневой структурой, в отличие от лаконичного JSON, чья спецификация умещается в шести диаграммах и почти не менялась два десятилетия. YAML активно развивается: версия 1.2 существенно отличается от 1.1, что приводит к разному parsing одних и тех же документов в разных реализациях.

Пример документа с настройками сервера демонстрирует проблемы YAML: числа вида 22:22 могут интерпретироваться как sexagesimal (1342) в версии 1.1, но как строка в 1.2. Якоря (&) и алиасы (*) усложняют чтение, а теги (!) создают угрозу выполнения произвольного кода при загрузке ненадёжных данных. Известная «проблема Норвегии» (неожиданная интерпретация сокращений стран) подчёркивает, что попытки быть «дружелюбным» формат делают его непредсказуемым и опасным.

• Критика YAML за его сложность, неоднозначность и множество подводных камней, таких как проблемы с автоматическим определением типов (например, "no" интерпретируется как false).
• Предложения использовать альтернативы: JSONC, TOML, HCL, Dhall, Jsonnet, CUE или всегда заключать строки в кавычки в YAML для избежания ошибок.
• Обсуждение отдельных проблемных особенностей YAML, таких как якоря/алиасы, сексегесимальные числа и необходимость в линтерах.
• Отмечается, что, несмотря на недостатки, YAML остается популярным из-за удобочитаемости и широкой распространенности.
• Упоминание, что спецификация YAML 1.2 (2009 г.) исправила некоторые проблемы, но многие issues остаются актуальными.

GitHub Actions добавили поддержку YAML-якорей, что автор считает серьёзной ошибкой. Якоря избыточны: ту же функциональность можно реализовать через встроенные механизмы вроде workflow-level env, которые прозрачнее и логичнее в архитектуре. Они вводят ненужную сложность, нарушая локальность — теперь элементы могут зависеть от частей конфигурации в совершенно другом месте файла, что усложняет чтение и анализ.

Кроме того, якоря усугубляют проблемы безопасности: инструментам сложнее анализировать workflows, так как нарушается соответствие между исходным YAML и объектной моделью. Это мешает точно отслеживать уязвимости, например утечки секретов. GitHub не реализовал ключи слияния (merge keys), единственный сценарий, где якоря могли бы быть оправданы, что делает их поддержку бессмысленной и вредной.

• Внедрение YAML-якорей в GitHub Actions оценивается положительно для устранения дублирования в конфигурациях, но критикуется за использование нестандартного синтаксиса, усложняющего анализ.
• Высказываются предложения заменить YAML на полноценный язык программирования для определения пайплайнов, чтобы улучшить тестируемость, локальную разработку и избежать сложностей шаблонизации.
• Поднимаются проблемы безопасности из-за неявного распространения переменных окружения (включая секреты) при использовании якорей и слияния объектов, что противоречит принципу минимальных привилегий.
• Отмечается, что текущие ограничения GitHub Actions (например, отсутствие фильтрации путей для workflow_call) вынуждают пользователей создавать костыльные решения или полагаться на сторонние инструменты.
• Обсуждаются компромиссы между декларативным и императивным подходами: одни предпочитают чистый YAML для читаемости, другие генерируют его из кода для удобства поддержки сложных логик.

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

Выбор языка для конфигурации — непростая задача. JSON кажется слишком техническим, TOML — слишком минималистичным. И тут возникает соблазн использовать YAML: он приятен глазу и популярен. Однако за кажущейся простотой скрываются pitfalls, как показывает печально известный «документ из ада». Со временем даже небольшой YAML-файл может превратиться в кошмар поддержки.

Корень проблемы не в выборе языка (YAML vs. альтернативы), а в том, что мы недооцениваем конфигурационные файлы как пользовательские интерфейсы. Они должны обеспечивать отличный UX: предотвращать ошибки, вести пользователя к успеху и работать как «велосипед для ума».

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

• Критика KSON за отсутствие чувствительности к пробелам, что может приводить к неочевидным ошибкам парсинга, как в примере с вложенным списком портов.
• Обеспокоенность рисками безопасности из-за единственной реализации на Kotlin и сложностей сборки для других языков, таких как Python и Rust.
• Предложение использовать полноценные языки программирования (например, Python) для конфигурации вместо специализированных форматов, чтобы дать пользователям больше инструментов.
• Аргумент в пользу того, что конфигурационные форматы должны быть выразительными, но ограниченными (как Cue, Starlark или Dhall), а не просто данными, как JSON или YAML.
• Подчёркивание различия между форматами для людей (конфигурация) и для компьютеров (данные), и критика попыток совместить их в одном формате.
• Замечание, что сложная конфигурация часто указывает на проблемы в дизайне ПО, и что лучше предоставить пользовательский интерфейс вместо сложных файлов.
• Упоминание альтернатив, таких как TOML, HJSON, HOCON, KDL и Jsonnet, с различными подходами к простоте, выразительности и проверке типов.

Murex.Rocks

Интуитивная и контекстно-ориентированная оболочка для современной командной строки.

Современная оболочка для всех

Murex предлагает множество уникальных возможностей:

Контекстная осведомленность

Нативная поддержка форматов данных: JSON, YAML, CSV и других. Типы данных могут быть явно приведены или выведены автоматически.

Выражения

Умная обработка переменных и выражений для предотвращения ошибок. Больше не нужно беспокоиться о специальных символах в именах файлов.

Интерактивность

Интуитивная интерактивная оболочка с подсказками из man-страниц и интеграцией с ИИ.

Расширяемость

Встроенный менеджер пакетов для простого обмена конфигурациями и переноса окружения между машинами.

Начало работы

• Тур по языку для старта
• Rosetta Stone как шпаргалка с сравнением Bash
• Интерактивная оболочка для использования в командной строке

Простая установка

Установите murex через ваш пакетный менеджер:

macOS:

brew install murex
# или
port install murex

Arch Linux:

wget -O PKGBUILD 'https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=murex'
makepkg --syncdeps --install

FreeBSD:

pkg install murex

Другие варианты в документе установки.

---

Лицензия GPLv2, Copyright © 2017-present Laurence Morgan

• Пользователи столкнулись с техническими проблемами при установке и запуске Murex, включая ошибки с aspell, HTTPS-протоколом и системными вызовами.
• Обсуждаются исторические и культурные отсылки в названии оболочки (Murex — моллюск, источник пурпурного красителя, значимый для финикийцев и иудеев).
• Поднимается вопрос о целесообразности изучения нового синтаксиса, несовместимого с Bash, и необходимости убедительных преимуществ для перехода.
• Murex сравнивается с альтернативными оболочками, в частности с Nushell и PowerShell, отмечается сходство в подходе к работе с структурированными данными.
• Критикуется маркетинг и описание проекта за отсутствие конкретных примеров и явных преимуществ перед существующими решениями.
• Отмечается, что для широкого применения скрипты должны быть совместимы с Bash, что ставит под вопрос нишевый потенциал Murex.
• Некоторые пользователи выражают заинтересованность в тестировании Murex при условии, что он будет стабильным и быстрым.

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.

desktop-tui — графикс-фри десктоп: терминальное окружение без X/Wayland.
Управляется клавиатурой, рисует рамки/окна в консоли, запускает TUI- и CLI-приложения.
Лёгкий, зависит только от ncurses и libc; конфиг на YAML.
Сборка: cargo build --release; запуск: ./target/release/desktop-tui.

• Пользователи сравнивают проект с DESQview, TWIN и TurboVision, спорят о целесообразности «переизобретения» оконного TUI-интерфейса.
• Основные плюсы: минимализм, низкое потребление ресурсов, удобство работы по SSH, возможность запуска на слабом железе (Raspberry Pi, VPS).
• Главные минусы: отсутствие браузера и современных коммуникационных приложений, проблемы с ресайзом, непонятные хоткеи, необходимость докачивать библиотеки.
• Некоторые советуют проверенные альтернативы: tmux+Emacs/Vim+SLIME, TWIN, Wordgrinder, browsh.
• Общий вывод: интересное решение для низкоуровневого или «отвлечённого» окружения, но пока требует документации и доработки.

bookmarks.txt — идея хранить закладки в обычных текстовых файлах.
Проект на GitHub: soulim/bookmarks.txt.

• Участники делятся на «быстрые закладки» (часто посещаемые сайты) и «долгосрочное хранение» (контент, который может исчезнуть).
• Популярны минималистичные форматы: plain-text, Markdown, YAML, .url-файлы, CSV, либо просто e-mail/рассылки.
• Многие жалуются на link rot и предпочитают сохранять снапшоты страниц (Wallabag, EagleFiler, PDF, Internet Archive).
• Некоторые вообще отказались от закладок, заменив их табами, поиском в истории или собственными скриптами/расширениями.
• Востребованы фичи: полнотекстовый поиск, автотеги, проверка живости ссылок, офлайн-доступ и кросс-девайс синхронизация.

Современные CI-платформы стали мощнее, но и сложнее. GitHub Actions, GitLab и др. предлагают YAML-конфиги с шаблонами, условиями, секретами, кешем, артефактами, экосистемой actions — в итоге CI превращается в полноценную систему сборки.

Базовые примитивы (задачи, зависимости, шаги) не отличаются от Makefile-ов, а добавление распределённого запуска и кеша делает CI почти идентичным современным билд-системам вроде Bazel.

Сложность растёт:

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

Итог: вместо простого «удалённого запуска тестов» мы получили громоздкую систему, где границы между CI и build-системой стёрлись.

• Участники сходятся во мнении, что современные CI-системы слишком сложны и слишком «далеко» от разработчика, превращаясь в гибрид билд-системы и платформы.
• Многие предлагают упрощение: локально-переносимые скрипты (Bash, Justfile, build.bash), контейнеры или минималистичные движки вроде builds.sr.ht, Drone OSS, Buildbot, Linci.
• Критика YAML-конфигураций и SaaS-зависимости: GitHub Actions «застрял», GitLab CI мощнее, но всё равно требует «платформы».
• Идея «CI должен быть просто расширением билд-системы» (Bazel, Nix, Dagger) звучит, но требует единого «Steve Jobs билд-систем», а не новых технологий.
• Итог: пока нет серебряной пули; кто хочет простоты — пишет ./build.sh и запускает где угодно, кто хочет мощности — мирится с уровнем сложности текущих CI.

Зачем нужен семантический слой и как собрать его на DuckDB

Когда не нужен

• Один инструмент аналитики (BI, ноутбук или приложение).
• Метрики тривиальны: COUNT, SUM, AVG.
• Все агрегаты уже материализованы в таблицах.

Зачем нужен

1. Единое место определения метрик – версионируемые YAML-файлы с бизнес-логикой, которые читают BI, ноутбуки, веб-приложения, AI.
2. Кеш и безопасность – быстрые ad-hoc-запросы без переноса данных, ролевая безопасность через API.
3. Согласованность – KPI «Выручка» описан один раз и не дублируется в каждом инструменте.

Минимальный пример

• metrics.yaml – 30 строк: название, SQL-выражение, формат, описание.
• run.py – 40 строк на Ibis + DuckDB: читает YAML, строит запрос к 20 млн записей NYC Taxi, возвращает DataFrame или SQL.

Как работает

import ibis, yaml, duckdb
ibis.options.interactive = True
con = ibis.duckdb.connect("nyc_taxi.ddb")
taxi = con.table("trips")

with open("metrics.yaml") as f:
    metrics = yaml.safe_load(f)

revenue = metrics["total_revenue"]["sql"]
result = con.sql(revenue).to_pandas()

YAML:

total_revenue:
  sql: "SELECT SUM(fare_amount) FROM trips"
  format: currency
  description: "Общая выручка"

Итог
Семантический слой решает проблему дублирования логики и ускоряет аналитику, когда данные и потребители разнообразны. Полный код – в репозитории semantic-layer-duckdb.

• Семантический слой — это абстракция, переводящая технические запросы в термины, понятные бизнес-пользователям, и обеспечивающая единые метрики, джойны и логику.
• Внедрение требует капитальных усилий: аналитики спешат сделать отчёт «здесь и сейчас», а не выделять время на переиспользуемую логику.
• Некоторые считают его «ORM для BI» или «VIEW на стероидах», но он шире: позволяет динамически компоновать представления без повторных вычислений.
• Инструменты варьируются от YAML-файлов до языков вроде Malloy; многие мечтают о встроенной поддержке в DuckDB или Looker-like BI.
• Главный риск — преждевременная абстракция; неправильные метрики закрепляются и тормозят развитие.

CLI-инструменты часто зависят от платформы/версии, плохо документированы и ломаются при не-ASCII вводе. Агенты путаются в управлении состоянием (например, tmux-сессиями) и теряют контекст после мелкой ошибки. Каждый вызов ещё тормозит из-за предварительной проверки безопасности.

Композиция в CLI работает через bash: цепочки tmux send-keys, sleep, base64 и т.д. MCP сегодня так не умеет.

Выход — MCP-сервер с одним «убер-инструментом»: Python-интерпретатор, сохраняющий состояние между вызовами. Пример — pexpect-mcp: виртуальное окружение + pexpect, позволяющее скриптами управлять интерактивными CLI-программами. Вместо 30 отдельных MCP-функций достаточно одной, принимающей код.

• Участники спорят, нужен ли MCP (Model Context Protocol): кто-то считает его лишним слоем, другие — полезным способом дать LLM структурированные инструменты.
• Критика: MCP ограничивает агента набором команд, не решает безопасность, дублирует OpenAPI и заставляет LLM учиться новому формату вместо bash/API.
• Альтернативы: прямое обращение к HTTP/CLI/WebSocket (UTCP), YAML-описание тулов (hooks_mcp), eval в песочнице (runjs, Bubblewrap).
• Практические проблемы: при 100+ тулов агент путается; приходится писать кучу обвязок вместо «просто вызвать API».
• Общий вывод: MCP пока выглядит сыро, требует лишних усилий и не даёт очевидных преимуществ перед строками/bash/API.

POML — язык разметки Prompt Orchestration Markup от Microsoft.
Проект в открытом доступе на GitHub: microsoft/poml.

• Назначение: структурировать, версионировать и переиспользовать промпты для LLM.
• Формат: YAML-подобный, читаемый человеком и парсером.
• Возможности:
  – параметризованные шаблоны,
  – условные ветвления,
  – импорт фрагментов,
  – метаданные (автор, версия, модель).
• CLI: poml build → компиляция в чистый текст, poml test → прогон с примерами.
• CI/CD: экшены GitHub для валидации и деплоя промптов.
• Интеграции: Python SDK, VS Code-расширение, экспорт в OpenAI, Azure, Bedrock.

• POML — это XML-подобный DSL от Microsoft Research для «view-слоя» промптов, но выглядит как «JSX, только хуже» и заставляет писать код в строках.
• Участники сравнивают его с YAML-промптами GitHub, BAML (TypeScript-подобные схемы), Jinja и обычным XML, споря о необходимости новой библиотеки.
• Критика: один контрибьютор при $3T-спонсоре, нет SDK для .NET/C#, лишний tooling, «IP squatting», циклы в XML выглядят как костыль.
• Ирония: из-за потребности в точности неформальные LLM-промпты всё структурнее, как юридические документы.

• Zitadel: JS-движок не поддерживает именованные группы в regex.
• Entra: PKCE есть, но не указан в OpenID-доке → клиенты думают, что нет.
• EXIF: размеры в метаданных могут не совпадать с реальными.
• YAML: пробелы ведут себя неочевидно.
• Windows: скрытые файлы нельзя открыть флагом "w"; опция SMB hide dot files усложняет жизнь.
• Git: автопреобразование LF ↔ CRLF ломает bash-скрипты.
• Cloudflare Workers: fetch по умолчанию использует http, даже если указан https.
• Android/iOS: без разрешения на геолокацию GPS-данные могут тихо удаляться из фото.
• PostgreSQL NOTIFY: работает в транзакции → WAL растёт каждые 5 с при использовании socket.io-адаптера.
• npm-скрипты: каждый запрос к реестру → плохой health-check.
• JS-«пакетный» спамер: добавляет 50 лишних зависимостей «для обратной совместимости».
• bcrypt: учитывает только первые 72 байта пароля.
• JS Date: годы и дни считаются с 1, месяцы — с 0.
• ESM ↔ CJS: до Node 20.8 смешанный импорт мог вызвать segfault.
• PostgreSQL: максимум 65 535 параметров — большие bulk-insert ломаются.
• Clipboard API и др. работают только в HTTPS/localhost.
• TypeORM: .remove() удаляет поле id из переданного объекта.

• Пользователи восторженно приняли идею «cursed knowledge» — каталога кошмарных нюансов, сопровождаемого коммитом-фиксом.
• Обсуждали PostgreSQL-лимит в 65 k placeholder’ов, причины появления 50 лишних npm-пакетов, скрытые потоки NTFS/ADS и «призрачные» файлы macOS.
• Упомянули, что bcrypt обрезает пароль до 72 байт, Cloudflare Workers могут игнорировать https, EXIF-даты в Immich — постоянная головная боль.
• Поделились личным опытом: неразрывные пробелы, case-insensitive имена в macOS, Java-классы в Oracle, «магия» YAML-парсеров.
• Кто-то предложил превратить подборку в репозиторий-«Awesome Cursed», другие подчеркнули пользу такого «терапевтического» лога ошибок.