Hacker News Digest

EPUB‑формат, как открытый стандарт, позволяет создавать электронные книги, которые корректно отображаются в большинстве приложений и устройств. Тем не менее Kobo официально отказывается принимать такие файлы в своей экосистеме и указывает на проблемы совместимости, связывая их с работой Adobe. По их версии, ошибки появляются из‑за того, как Adobe обрабатывает метаданные, реализует DRM и генерирует файлы EPUB3, а не из‑за недостатков самого стандарта. Кроме того, Kobo требует строгий XML‑манифест и определённые метаданные, которые часто нарушаются в результате автоматической конвертации Adobe.

Кроме того, аналитика показывает, что около 70 % всех жалоб о несовместимости напрямую связаны с обработкой DRM‑защищённых EPUB‑книг в Adobe Reader, тогда как открытые книги без защиты открываются без проблем на Kobo и других платформах. Компания подчёркивает, что её собственный формат основан на EPUB, но содержит дополнительные ограничения, которые облегчают контроль над контентом. Поэтому рекомендация – конвертировать книги в поддерживаемый формат или использовать альтернативные читалки, а также, при необходимости, удалять DRM‑защиту, чтобы восстановить полноценную работу EPUB‑файлов. Таким образом, проблема остаётся в реализации Adobe, а не в самом стандарте.

• Adobe RMSDK устарел, часто «падает» и не поддерживает современные CSS‑стандарты, что приводит к проблемам с валидацией EPUB.
• Kobo использует собственный движок (Kepub) для файлов с расширением .kepub.epub, но обычные .epub проходят через старый Adobe‑движок, вызывая ошибки отображения.
• Альтернативные читатели, такие как Koreader и Calibre‑конвертер, обеспечивают лучшую совместимость и поддержку современных CSS‑возможностей.
• При публикации нужно ориентироваться на «наименьший общий знаменатель» – простые стили и минимум CSS, чтобы избежать проблем с разными e‑reader‑платформами.

Страница XSLT.RIP объявляет о смерти технологии XSLT, обвиняя в этом Google. На минимальной веб-странице всего три строки: заголовок "Если вы это читаете, XSLT был убит Google" и два коротких соболезнования. Это мемориальная страница, созданная в знак уважения к технологии, которая, по мнению автора, прекратила свое существование из-за действий Google.

Страница оформлена в виде простого XML-документа с XSLT-стилем, что создает ироничный контент. Несмотря на скудность информации, это явный протест против прекращения поддержки XSLT, технологии, которая долгое время использовалась для преобразования XML-документов. Фраза "Rest in peace" (Вечная память) подчеркивает, что автор рассматривает это как окончательную кончину технологии, а не просто изменение в политике поддержки.

• Google не «убивает» XSLT, а лишь прекращает поддержку в браузере, что вызывает споры о том, насколько это технически оправдано.
• Сайт xslt.rip использует нарочито ретро-дизайн, чтобы подчеркнуть иронию ситуации, но это вызывает споры о том, насколько это уместно.
• Обсуждение поднимает вопрос о том, что XSLT всё ещё используется в медицинских записях и других нишах, где XML по-прежнему важен.
• Некоторые участники считают, что Google просто не хочет вкладывать ресурсы в поддержку устаревших стандартов, в то время как другие считают, что это естественный процесс устаревания технологий.

После четырёх лет разработки Stalwart представил полную реализацию JMAP для календарей, контактов, адресных книг, хранения файлов и обмена. Это делает Stalwart первым сервером JMAP, поддерживающим всю семью протоколов совместной работы, открывая новую эру для открытого и эффективного группового ПО. Новые стандарты включают JMAP для Календарей (замена CalDAV), Контактов (альтернатива CardDAV), Файлов (замена WebDAV), а также JSCalendar и JSContact — современные JSON-версии iCalendar и vCard.

JMAP решает проблемы устаревших технологий, предлагая вместо громоздкого XML и несовместимых форматов простые, последовательные API поверх JSON. Протоколы обеспечивают лучшую производительность, простоту реализации и надёжность. Эта реализация знаменует сдвиг в проектировании ПО для совместной работы, позволяя разработчикам строить на единой, когерентной платформе. Поддержка клиентов пока развивается, но такие проекты, как Mailtemi и Parula, уже работают с новыми стандартами.

• Stalwart — первый сервер с полной поддержкой JMAP, но документация и UX оставляют желать лучшего, что затрудняет его внедрение.
• JMAP-совместимые клиенты всё ещё отсутствуют, что делает внедрение Stalwart сложным для конечных пользователей.
• Отсутствие клиентов и серверов, поддерживающих JMAP, затрудняет внедрение, даже если Stalwart технически превосходит IMAP и CalDAV.
• Сообщество обсуждает, что для внедрения JMAP нужно как минимум один из: либо крупный провайдер (Gmail, Fastmail) начнёт поддерживать его, либо Thunderbird и другие клиенты добавят поддержку.

В Kotlin-компиляторе скрыта ошибка, срабатывающая при сборке проекта в турецкой локали. Из-за неё при попытке скомпилировать код в турецкой локали возникает ошибка парсинга XML от компилятора: строчка var category: CompilerMessageSeverity? = CATEGORIES[qName.toLowerCase()] в функции CompilerOutputParser некорректно обрабатывает турецкий символ I (U+0049), который при приведении к нижнему регистру становится не i (U+0069), а ı (U+0131) — точкой надстрочного i без точки. Из-за этого ключ i не находится в словаре CATEGORIES, и код ошибочно считает, что это неизвестный тег, и выдаёт сообщение об ошибке.

Ошибка скрывалась в коде с 2016 по 2021 год, пока не была обнаружена и исправлена. Теперь код корректно использует локально-независимый toLowerCase(Locale.ROOT), и проблема решена. Это яркий пример того, как тонкости локализации могут вызывать ошибки в интернационализированном ПО, особенно при обработке текста.

• Проблема "турецкое I" встречается везде, где не указывается локаль при работе со строками, и это приводит к багам, когда вместо "I" в турецкой локали превращается в "ı" (без точки) и наоборот.
• Современные языки и фреймворки должны предоставлять единообразные и предсказуемые API, но вместо этого они вынуждают разработчиков указывать локаль каждый раз, что приводит к ошибкам.
• Пользователи с турецкой локалью страдают от багов, которые не могут быть обнаружены автоматически, потому что большинство разработчиков тестируют только на английской локали.
• Это также является примером более широкой проблемы: API-функции, которые не принимают Locale параметр, вместо этого полагаясь на дефолтной локали, что может привести к ошибкам.

Как RSS победил Microsoft

Корпоративные гиганты пытались монополизировать контент-синдикацию, но проиграли простому формату.

ICE vs RSS: закрытость против открытости

В 1998 году Microsoft, Adobe, CNET и другие запустили спецификацию ICE — дорогой, сложный и закрытый стандарт для лицензирования и перепубликации контента. ICE обещал издателям контроль и монетизацию, но требовал $50 000 за сервер и поддержку консорциума.

RSS появился в 1999 как бесплатный XML-виджет на портале My Netscape: любой блоггер мог добавить ленту обновлений в общий список «каналов». Формат был проще, короче и не требовал денег.

Деньги vs массы

ICE продавали крупным издателям: Reuters, Vignette, iSyndicate. RSS раздавали бесплатно: первые агрегаторы Headline Viewer и my.userland.com запустились без бюджета и без лицензий. Пока консорциум взимал плату, тысячи блоггеров уже создавали ленты в блокноте.

Итог

К 2005 году ICE умер: дорого, сложно, никто не пришёл. RSS стал воздухом: читалки, подписки, podcast-фид. Победил не потому что был лучше технически, а потому что был открытым и бесплатным.

• RSS удобен читателям, но не выгоден издателям: в ленту сложно встроить рекламу и отследить аудиторию.
• Пользователи по-прежнему цепляются за RSS: уходят с платформ, которые его убрали (Twitter, Reddit), и сами собирают фиды.
• Google Reader убил, а не стандарт: после закрытия сервиса ленты исчезли, но подкасты, XKCD, Microsoft-фиды живы.
• Технически RSS «мёртв» 15 лет, по факту — нишевой, но стабильный инструмент; альтернативы (ICE, ActivityPub) не прижились.
• Новые идеи: RSS-газета на бумаге, JSON-лента, почтовые ящики внутри ридеров — всё решает те же старые проблемы монетизации и курирования.

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-окружении» повторяется как ключевой.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

Репозиторий демонстрирует, как обойтись без движков шаблонов, используя лишь стандартные XML-технологии.

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.