Hacker News Digest

Митчелл Хашимото делится личным опытом, как не теряя мотивации довести большие проекты до конца. Он начинает с маленького, но ощутимого результата: например, вместо «сделать терминал» он берёт подпроект «распарсить VT-коды» и уже через пару дней имеет живой результат и тесты. Далее он итеративно добавляет новые фичи, каждый раз имея что-то, что можно показать. Это позволяет сохранять энтузиазм и не терять фокус. Под конец он напоминает, что не стоит стыдиться незавершённых проектов — главное, чтобы они были интересны самому автору.

• Собеседники подчеркнули, что ключ к быстрому прогрессу — это умение разбивать задачу на мелкие, легко демонстрируемые фрагменты и не застревать в «анализ-парализе»; главное — быстро получать обратную связь и не бояться «грязного» MVP.
• Подчеркнуто, что выбор инструмента (язык/стек) влияет на скорость итераций: REPL-языки и инструменты вроде hot-reload позволяют видеть эффект изменений почти мгновенно, что снижает порог входа и удерживает мотивацию.
• Участники обсуждения подтвердили: чем раньше показать работающий прототип, тем меньше вероятность, что проект застрянет в вечной «доработке»; демо-ориентированная разработка заставляет фокусироваться на ценности для пользователя, а не на перфекционизме.
• Сообщество отметило, что даже в личных проектах важно документировать и тестировать как будто ты передашь его другу: это упрощает возврат к контексту спустя месяцы и служит живым примером.
• Несколько человек поделились личным опытом, что их подход к разработке ПО вдохновил их начать вклад в open-source, и что их опыт в open-source в свою очередь улучшил их навыки ведения личных проектов.

Разработчик выложил на Hacker News фреймворк на C, и я, как исследователь безопасности, сразу заметил три классические ошибки: не проверяемый Content-Length, переполнение при копировании тела запроса и переполнение при записи ответа. Пример кода показывает, как непроверенное поле Content-Length используется как размер для malloc и memcpy, что может привести к утечке памяти или чтению за пределы буфера. Подобные проблемы встречаются везде, где C-фреймворки принимают ввод из сети или файловой системы.

• Обсуждение крутится вокруг того, что «хороший код на C» должен минимизировать выделение памяти и избегать atoi() и strdup() без проверки ошибок, что приводит к уязвимостям.
• Участники спорят о том, насколько критичны эти проблемы в контексте обучения и использования ИИ-помощи, и о том, что новички в C могут не осознавать эти ловушки.
• Обсуждается влияние ИИ на качество кода и безопасность, а также то, что влияние ИИ на обучение языкам может маскировать проблемы, которые иначе были бы очевидны.
• Участники также обсуждают, что влияние ИИ на обучение языкам и на то, что это может привести к проблемам, если человек не понимает, что делает ИИ, и что это может быть опасно.
• В обсуждении также поднимается вопрос о том, что ИИ может быть использован для аудита кода и нахождения проблем, и о том, что это может быть использовано для улучшения качества кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

Проект mafik/keyer — это прошивка и утилиты для создания однорукого хордового клавиатурного устройства KEYER. Он работает на любой платформе, где есть USB-host, и поддерживает 3 клавиатурных слоя: основной, символы и цифры. Проект полностью открыт: исходники, схемы, документация и 3D-печатные файлы корпуса. Подключение через USB-C, встроенный аккумулятор 110 мАч, поддержка QMK/VIA и Vial.

• Проект демонстрирует, что ESP32 может быть клавиатурой, а моделлиновая глина — корпусом.
• Участники обсуждают, что такое устройство может быть полезно для VR/AR, игровых шорткатов и даже для людей с ограниченными возможностями.
• Некоторые комментаторы упоминают существующие продукты, такие как Twiddler и Razer Tartarus, и обсуждают их преимущества и недостатки.
• Обсуждается безопасность использования литий-ионных батарей без защитного корпуса и возможность использования термопластика вместо глины.
• Участники также обсуждают, что такое устройство может быть полезно для людей, которые хотят использовать его для ввода читов или шорткатов в играх, и что оно может быть полезно для людей с ограниченными возможностями.

Почему стоит заняться самостоятельным хостингом? Во-первых, это ключ к приватности: ваши календари, контакты, местоположение и прочие данные остаются под вашим контролем, а не в руках Big Tech. Во-вторых, вы получаете полный контроль над своими данными и не зависите от политик компаний, которые могут в любой момент заблокировать ваш аккаунт без объяснения причин. И, наконец, это способствует цифровому суверенитету и самообеспечению.

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