Hacker News Digest

Статья в интерактивном формате объясняет, как работает Burrows-Wheeler Transform (BWT) — алгоритм, который лежит в основе сжатия bzip2 и инструментов выравнивания последовательностей bowtie/bwa. Суть BWT в том, что он группирует идентичные символы, а затем позволяет точно восстановить исходную строку. Для демонстрации автор кодирует слово «banana» и показывает, как появление символа $ вращает матрицу, делая обратное преобразование возможным. В статье также показано, как поиск подстроки сводится к просмотру первого и последнего столбцов, и как это используется в биоинформатике для выравнивания ДНК-чтения.

• BWT позволяет искать подстроку за O(l) времени и имеет O(n) памяти, что делает его одним из самых элегантных алгоритмов, которые я когда-либо встречал.
• Сложность в понимании BWT часто заключается в том, что «сортировать» означает лексикографически сортировать все вращения, а не просто сортировать строку.
• Публикация алгоритма была отвергнута, и вместо этого он был опубликован как DEC тех. отчет, что является интересным фактом.
• Суффиксные массивы и BWT взаимно-обратны, и это свойство используется для поиска подстроки в O(l) времени.
• Несмотря на то, что BWT сам по себе не сжимает данные, он является ключевым шагом в bzip2 и других алгоритмах сжатия без потерь.

Разработчики часто сталкиваются с тем, что официальная документация описывает функцию, но не показывает, как её использовать. Пример: вместо того, чтобы показать, как вызывать max() в Python, документация тратит абзацы на то, чтобы объяснить, что такое iterable и что значит key=. А ведь достаточно было бы показать, как передавать кастомную функцию сортировки в max().

Проект ClojureDocs берёт на себя роль «примеры — лучшая документация». Пользователи добавляют примеры к встроенным функциям, и это оказывается куда более полезным, чем формальное описание API. Примеры показывают, как вызывать функцию, какие есть подводные камни и какие есть альтернативы.

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

Главная идея: бюрократия США заставила мексиканца отказаться от имени, данного ему при рождении, и теперь он вынужден жить под именем «Джо». Автор рассказывает, как его имя и фамилии, унаследованные от четырех дедов, были по одному бюрократическому штампу «отказано в визе» — и как это влияет на повседневную жизнь вплоть до того, что бариста Starbucks не может произнести заказ в кафе. Он также подсчитал, что потеря имени стоила ему уже около $1000 на гринкарте, потому что «имя в паспорте не совпадает с именем в системе» вынуждает авиакомпании снимать с него деньги за пересадки.

• Различные культурные и языковые особенности имён (включая гендерные фамилии, транслитерацию, транслитерацию и т.д.) вызывают системные проблемы, которые не решаются десятилетиями, и вместо этого приводят к бюрократическому хаосу и дискриминации.

• Имя человека — это не просто набор символов, а часть его идентичности, и системы должны быть гибкими и уважительными к различиям.

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

• Системы должны быть спроектированы так, чтобы они были устойчивы к различным форматам имён и не требовали бы точного совпадения, чтобы избежать дискриминации и ошибок.

• В конечном счёте, это вопрос уважения к человеческому разнообразию и признания того, что имена могут быть сложными, и что это не должно быть причиной для отказа в обслуживании.

Пользователи Hacker News обсуждают, что делать, если твой проект на GitHub внезапно взлетел: за 12 часов он собрал 1000 звёзд, попал на главную страницу и начал приносить деньги. Кто-то предлагает «не вздумай трогать репозиторий», другие советуют «сделать его ещё лучше и не трогать». Тем не менее, большинство сходится на том, что важно не потерять моментум и продолжать фокусироваться на продукте и сообществе.

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

Краткий пересказ

30 сентября 2025 года бывший сотрудник Ruby Central Андре Арко сообщил, что у него остался доступ к продакшен-среде RubyGems.org. Почти одновременно блогер Джоэл Дрейпер опубликовал скриншоты, подтверждающие это. Внутреннее расследование показало, что 19 сентября неизвестный злоумышленник сменил пароль root-аккаунта AWS и в течение 11 дней имел возможность администрировать инфраструктуру. В результате Ruby Central отозвала все устаревшие ключи доступа, включила MFA для всех живых аккаунтов и перевела проект на изолированный AWS-аккаунт под единоличным контролем Ruby Central.

• Ruby Central обвиняет бывшего мейнтейнера Andre Arko в том, что он, будучи уволенным, сохранил доступ к корневой учетной записи AWS и изменил пароль, что фактически блокирует организацию от доступа к собственной инфраструктуре.
• Сообщение Ruby Central подчеркивает, что не было никаких доказательств компрометации, но не упоминает о том, что не было никаких доказательств и того, что доступа не было.
• Сообщение Ruby Central не упоминает о том, что они не отозвали доступа к корневой учетной записи, не изменили пароль и не отключили MFA, что, как утверждает Arko, оставляет сервис уязвимым для "незаконного доступа и потенциального утечки данных".
• Arko утверждает, что он не имел доступа к логам доступа, и что Ruby Central не предоставила никаких доказательств того, что кто-то еще имел доступ к этим логам.
• Обсуждение также затрагивает вопрос о том, каким образом Ruby Central может гарантировать, что никакие PII не была скомпрометирована, если они не могут доказать, что никто не имел доступа к логам доступа.

Subway Builder — это гиперреалистичный симулятор метро, где вы строите подземку в настоящем городе, учитывая реальные ограничения и цены. Игра использует настоящие данные о пассажирах и дорогах, чтобы вы могли бы оптимизировать маршруты и нести ответственность за задержки и пересадки. Стоимость — 30 долларов на сайте и 40 долларов в Steam.

• Игроки жалуются на ранний доступ, отсутствие демо-версии и высокую цену, а также на то, что доступны только американские города.
• Сомнения в том, что игра готова к релизу: отсутствие демо-версии, неясность статуса и цены.
• Некоторые игроки считают, что игра не готова к релизу и что она стоит слишком дорого.
• Обсуждается, что игра может быть в раннем доступе на долгое время, и что она может быть в раннем доступе на долгое время.
• Игроки спрашивают о наличии демо-версии, поддержке других городов и о том, когда игра будет доступна в Steam.

Twitter/X теперь требует включённый JavaScript и блокирует просмотр без него. Пользователи с блокировщиками скриптов или расширений, которые ограничивают JS, теперь видят сообщение о недоступности JavaScript и предлагают «попробовать снова». Это делает невозможным просмотр даже статического контента без JS.

• Обсуждение выявило, что LLM-ы склонны к чрезмерно защитному стилю кода, который, как выясняется, может быть вызван RLHF и набором данных, где «правильный» код — это тот, который перестраховывается на каждом шаге.
• Участники обсудили, что «защитный» код может быть не только избыточным, но и логически неверным, поскольку он может маскировать ошибки, которые в продакшене не должны быть проглочены.
• Некоторые участники отметили, что вместо того, чтобы учить модель писать «правильный» код, стоит сфокусироваться на том, чтобы она училась различать, когда действительно нужна обработка ошибок, а когда можно обойтись без нее.
• Также было отмечено, что вместо того, чтобы писать в защитном стиле, лучше бы научить модель писать код, который не делает глупых ошибок в первую очередь.

Blaze — это высокопроизводительный полнотекстовый поисковый движок на Go, который специализируется на скорости и простоте использования. Он использует индексирование на основе памяти и поддерживает полнотекстовый поиск, включая поиск по префиксу, суффиксу и фразам. Проект разработан для того, чтобы быть легко встраиваемым в любое приложение, которое требует быстрый и эффективный поиск. Blaze использует современные алгоритмы сжатия и индексации, такие как Brotli и Snappy, для оптимизации производительности и использования памяти. Он также поддерживает горизонтальное масштабирование и может быть развернут в облаке. Проект имеет открытый исходный код под лицензией MIT и активно поддерживается сообществом.

• Проект представляет собой учебный пример полнотекстового поискового движка, написанный на Go, с акцентом на внутреннее устройство индекса и простоту кода.
• Автор отказался от парсинга строковых запросов, чтобы не отвлекать внимание от того, как устроен индекс.
• Несколько участников обсуждения отметили, что проект не лицензирован и не имеет лицензии, что может затруднить его использование.
• Другие участники предложили сравнить производительность с Lucene и Bleve, а также рассмотреть возможность интеграции с векторными базами данных.
• Автор ответил, что проект задуман как учебный пример, а не как полноценная замена существующим решениям.

ESP32 и Termux: как прошить Micropython на ESP32 прямо с телефона

• Подготовка: ESP32-WROOM-32, OTG-кабель, USB-кабель, Termux.
• TCPUART – мост между Android и ESP32, который создаёт локальный TCP-сервер на порту 8080.
• Подключение: socat в Termux связывает виртуальный порт /dev/esp32 с TCP-сервером.
• Режим загрузки: удерживаем BOOT, нажимаем EN → ESP32 в download-режиме.
• Сброс памяти: esptool erase_flash – чистим флеш.
• Прошивка: esptool write_flash – Micropython 1.26.1.
• REPL в Termux: mpremote connect port:$HOME/esp32 repl – готовый контроллер можно запускать прямо в телефоне.

Итог: ESP32 с Micropython без ПК, только с телефона.

• Обсуждение вращается вокруг использования Android-устройств как полноценной рабочей среды разработки, включая вопросы с доступом к аппаратному обеспечению, использовании Termux и других инструментов, и сравнение с настольными Linux-системами.
• Участники обсуждают различные аспекты: отсутствие нормального доступа к железу, проблемы с библиотекой Bazel и ее влиянии на сборку, возможность использования NDK и создания нативных бинарников, а также альтернативы вроде UserLAnd и Linux Deploy.
• Также поднимаются темы вроде запуска Home Assistant внутри Termux, использования Raspberry Pi как моста для ESP32, и влияние отсутствия реального Linux ядра в Android на различные аспекты.
• Наконец, обсуждается влияние отсутствия реального контроля над графическим стеком и как это влияет на разработку и использование Termux как основной рабочей среды.

Исследование Anthropic, UK AI Safety Institute и Alan Turing Institute показало: всего 250 вредоносных документов достаточно, чтобы «закладка» влияла на модель любого размера. Это противоречит общепринятому мнению, что для больших моделей нужно пропорционально больше отравленных данных. Подробности: https://arxiv.org/abs/2510.07192.

• Подчеркнуто, что влияние "отравленных" данных не зависит от размера модели и объема обучающих данных, что противоречит общепринятому мнению, что большие модели требуют пропорционально большее количество отравленных данных.
• Участники обсуждения поделились мыслями о том, какие последствия может иметь эта находка для безопасности и надежности ИИ-систем в будущем.
• Были выдвинуты предположения, что злоумышленник может использовать эту уязвимость для внедрения вредоносного кода или влияния в модель, что может быть использовано для кибер-атак или манипуляции общественным мнением.
• Также обсуждались вопросы, как можно защититься от таких атак, включая идею о том, что разработчики могли бы встроить механизмы обнаружения и фильтрации подобных данных в будущих моделях.
• Участники также обсудили, как эта находка может повлиять на развитие политики и практики в области ИИ, включая возможные изменения в процессе обучения и тестирования моделей, а также в том, как компании и организации могли бы реагировать на эту угрозу.