Hacker News Digest

Борьба с «инновационными токенами» — ключ к устойчивому росту. Каждый проект получает всего три шанса на радикальные технологические эксперименты; их расходование на эксперименты вроде NodeJS, MongoDB или новейших сервисов обнаружения приводит к риску провала. Вместо этого выбирайте «скучные», но проверенные решения — MySQL, Postgres, PHP, Python, Memcached. Их известные слабые места позволяют заранее спланировать отказоустойчивость, в отличие от новых технологий, где неизвестные неизвестные часто оказываются катастрофическими.

Оптимизация должна быть глобальной: фокус на долгосрочной стабильности, а не на блеске. В Etsy, используя «скучный стек», команда масштабировала активности в 20 раз без вмешательства, пока не отвлеклась на новые решения. Это подтверждает, что сознательный отказ от избыточной инновации ускоряет успех, а не замедляет его.

Тред критикует концепцию «инновационных токенов» как излишне упрощённую, подчёркивая, что выбор технологий должен основываться на конкретных потребностях проекта, а не на новизне. @NickNaraghi считает её полезной для принятия решений, но @insanitybit, @threethirtytwo и @euthymiclabs возражают: новизна не заменяет надёжность и стабильность. @gaigalas предлагает компромисс — 80% «скучных», 20% инновационных технологий, чтобы избежать конфликтов.

Архив представляет собой единственное собрание публичных PoC‑эксплойтов и обзоров уязвимостей, которые на момент публикации ещё не получили официального CVE. Автор разместил их в открытом доступе, призывая сообщество самостоятельно сообщать о найденных уязвимостях и забирать кредит за присвоенный номер, если он будет выдан. При этом он подчёркивает, что такие материалы предназначены лишь для привлечения людей в область кибербезопасности, а не для реального злоупотребления. Он также шутит, что можно «взять лулз», сообщая о уязвимостях и получая CVE, но настоятельно просит не злоупотреблять этим ресурсом.

Автор заявляет, что такие материалы следует использовать только в образовательных и исследовательских целях, а не для создания атак или распространения вредоносного кода. Он считает, что открытый набор PoC‑ов — самый эффективный способ заинтересовать начинающих специалистов, заставить их практиковаться с реальными примерами и ускорить развитие компетенций в области уязвимостей. При этом он подчёркивает, что злоупотребление архивом может привести к блокировке доступа к ресурсам, потере репутации и юридическим последствиям. Таким образом, репозиторий служит не столько как хранилище эксплойтов, сколько как стимул для ответственного исследования, способствующий формированию более безопасного программного обеспечения.

• Большинство упомянутых уязвимостей – лишь типичные баги или уже исправленные CVE, а термин «0‑day» здесь сильно размыт.
• Некоторые находки действительно интересные (например, уязвимости в c‑ares, nginx, PHP), но их эксплуатация часто требует предварительных условий.
• Большая часть репозитория содержит PoC‑ы, сгенерированные LLM, и их публичное распространение служит скорее образовательной цели, чем реальной угрозой.
• Автор предупреждает о недобросовестном использовании материалов и подчёркивает, что многие «эксплойты» – лишь учебные примеры, а не готовые атаки.

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Инженеры часто иррационально подходят к выбору языков программирования, принимая решения на основе идентичности, эмоций и эго, а не технических преимуществ. Автор делится историей о компании Takkle, где опытный CTO инициировал переход с PHP на Perl, что привело к девятимесячной задержке, увеличению расходов с $200K до $500K в месяц и, в конечном итоге, к банкротству компании. Несмотря на то, что PHP был «достаточно хорош» для Facebook, подобного решения не приняли.

В течение своей карьеры автор наблюдал повторяющуюся эту модель в Google, MongoDB и других компаниях. Он описывает случай, когда VP Engineering представил руководству обоснование выбора Rust, хотя Go объективно соответствовал заявленным критериям лучше. Оказалось, что другие языки даже не рассматривались — решение было основано на хайпе. Автор подчеркивает, что при обсуждении языков программирования всегда происходит два диалога: видимый технический и невидимый, связанный с идентичностью инженера.

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

Эндрю Шмеляун создал систему, позволяющую незнакомцам отправлять ему сообщения через чековый принтер. Он вдохновился другом, у которого на сайте была похожая функция, но хотел сделать её более физической. Эндрю использовал старый термопринтер Epson TM-T88IV, купленный на eBay за $50, который работает за счёт нагрева специальной бумаги, покрытой термочувствительным веществом. Поскольку принтер не распознаётся его Mac Mini, он подключил его к Raspberry Pi 4.

Для реализации проекта Эндрю выбрал PHP с фреймворком Laravel, создав сайт с простой формой без JavaScript. Система сохраняет сообщения в базу данных на случай, если принтер выйдет из строя или закончится бумага. Принтер имеет ограниченный набор символов (только стандартный алфавит, цифры и базовые знаки клавиатуры), поэтому сообщения проходят валидацию на предмет специальных символов. Ширина текстового поля соответствует ширине печати (42 символа).

• Пользователи делятся опытом с дешёвыми китайскими термопринтерами, драйверы и библиотеки для них, а также вспоминают проект Little Printer и другие попытки сделать «интернет-подключённые» термопринтеры.
• Обсуждаются вопросы безопасности при работе с термобумагой, влияние BPA и аналогичных пластификаторов, а также трудности с поставками безопасной бумаги.
• Участники делятся личным опытом: кто-то использует принтер как «интернет-факс», кто-то печатает стикеры из чека, кто-то пытается повторить Little Printer.
• Поднимается вопрос о том, что такие проекты могут быть использованы для печати зинов и других офлайн-контента.
• Также обсуждается, что при должном подходе можно было бы сделать такие проекты более доступными и устойчивыми к спаму и злоупотреблениям.

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

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

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

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

Репозиторий 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-фреймворков.