Hacker News Digest

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

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

Ruby Central сообщила о «событии безопасности» в RubyGems.org, но в действительности оно оказалось конфликтом между организацией и бывшим оператором Андре Арко, который вёл службу более 10 лет. Ruby Central утверждает, что он «не имел доступа» к продакшену, но не предоставляет никаких доказательств. Арко же утверждает, что у него оставался доступ к AWS и логам, и что он не мог бы их использовать без ведома. Он также утверждает, что его удалили из организации без объяснений, и что команда не отвечает на его письма. Он также утверждает, что Ruby Central не отвечает на его письма и не предоставляет никакой информации о «безопасности» RubyGems.

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

Клинопись — самая древняя из всех систем письменности, и её можно выучиться за 5 минут. В видео демонстрируется, как из глины и палочки для письма можно за минуту сделать табличку с именем «Сара» и «Том» и даже «Клинопись» на клинописи. Подчеркнуто, что в музее Британского музея есть 130 000 табличек, и что клинопись была слоговой, а не алфавитной, и что в ней 600-700 знаков. Видео также показывает, как можно было бы выучить клинопись за 6 лет.

• Обсуждение началось с демонстрацией часов на клинописи и ссылкой на HN, но быстро перешло к спорам о точности формулировок, где кто-то указал, что "the oldest writing system" следует заменить на "the oldest known writing system", а другой участник подчеркнул, что клинопись не самая древняя система письма, а лишь самая древняя из известных нам.
• Участники обсудили, что клинопись не является ни слоговой, ни алфавитной системой, а представляет собой смесь логограмм, слоговых и алфавитных знаков.
• Также обсуждались вопросы о том, что клинопись не может быть самой древней системой письма, так как существуют доказательства, что более древние системы могли существовать, но не сохранились.
• Были подняты вопросы о том, что клинопись не может быть самой древней системой письма, так как существуют доказательства, что более древние системы могли существовать, но не сохранились.

pgEdge выпустил open-source-утилиту spock — логическую репликацию PostgreSQL с поддержкой multi-master. Проект позиционируется как замена Bucardo и Slony, но с фокусом на высокую доступность и отказоустойчивость. Под капотом — использование логической репликации, что позволяет конфликтам разрешаться на уровне транзакции, а не на уровне отдельных запросов. Это делает spock пригодным для кластеров, где каждая нода может принимать запись.

Проект написан на C и Python, распространяется под лицензией PostgreSQL. Поддерживает PostgreSQL 12-16 и требует расширение pglogical.

• Разработчики подчеркнули, что multi-master репликация не обеспечивает такую же строгую согласованность, как PostgreSQL, и что это важно учитывать при выборе решения.
• Участники обсуждали, что при использовании multi-master репликации важно понимать, какие именно edge cases могут возникнуть и как они решаются.
• Были упомянуты такие решения, как CockroachDB и pgEdge, и обсуждались их плюсы и минусы по сравнению с другими решениями.
• Также обсуждались вопросы лицензии и лицензионной политики, а также то, какие именно ограничения могут быть связаны с использованием таких решений.
• В конце обсуждения было отмечено, что важно понимать, что multi-master репликация не решает всех проблем масштабирования и что важно тщательно оценивать, подходит ли она для конкретного use case.

Ученые из Пенсильванского университета обнаружили в стволе мозга «выключатель боли» — нейронную цепочку, которая может прервать сигнал хронической боли. Это открытие может стать основой для новых методов лечения, если удастся измерить и воздействовать на эти нейроны.

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

Разработчик Chromium Брюс Доусон обнаружил, что VS Code течёт дескрипторы процессов: вместо того чтобы закрывать дескриптор после использования, он оставляет его открытым. Каждый незакрытый дескриптор «стоит» 64 КБ, и при длительной работе редактора это может привести к утечке гигабайтами памяти. Проблема была найдена и исправлена в течении пары дней после доклада, и в релизе 1.94 VS Code больше не течёт.

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

Статья в интерактивном формате объясняет, как работает 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, если таковой существует.