Hacker News Digest

Автор провёл эксперимент с ригатони, сравнив фактическое время варки с рекомендациями на упаковке (13–15 минут). Измерения показали, что его семья предпочитает пасту al dente уже через 9–12 минут, причём идеальное время для него — 10:15, а для других членов семьи — от 9:45 до 11:30. К 12:45 все сошлись во мнении, что паста становится слишком мягкой.

Интересно, что дядя автора, выросший в Риме, отметил, что американцы склонны переваривать пасту. Попытка изучить структурные изменения под микроскопом не дала чётких результатов, но стала весёлым занятием для детей. Практический вывод: сокращение времени варки не только улучшает текстуру, но и снижает гликемический индекс.

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

• Участники обсуждают природу абстракции в математике, отмечая, что она была присуща ей изначально, а не стала результатом недавнего развития.
• Поднимается вопрос о связи математики с реальностью: одни считают её чисто абстрактной наукой, другие — инструментом, тесно связанным с естественными науками.
• Обсуждаются исторические кризисы и фигуры (Кантор, Фурье, Бурбаки), которые способствовали развитию абстракции и новых математических направлений.
• Упоминается, что абстракция часто служит для упрощения и обобщения, позволяя применять математический аппарат из одной области к проблемам другой.
• Некоторые участники делятся личными историями о том, как абстрактные математические концепции (сравнение бесконечностей, проблема остановки) повлияли на их жизнь.

Разработчики всё чаще сталкиваются с увеличением времени на модификацию или исправление кода, сгенерированного большими языковыми моделями. Это явление, названное «долгом понимания», напоминает работу с унаследованными системами, где перед внесением изменений необходимо глубоко разобраться в логике и контексте кода. Однако масштаб проблемы стал беспрецедентным из-за лавинообразного роста объёмов нечитаемого кода, который ИИ-инструменты производят с огромной скоростью.

Команды, заботящиеся о качестве, тратят время на ревью и рефакторинг такого кода, сводя на нет первоначальную экономию времени. Другие же просто коммитят непроверенные и непонятые фрагменты, создавая риски на будущее. Хотя ИИ может помочь с 70% правок, остальные 30% приводят к «петлям безысходности», когда модели не справляются с задачей, и разработчикам приходится разбираться в чужом коде самостоятельно. Это накопление долга понимания становится бомбой замедленного действия для миллионов проектов.

• LLM-генерация кода ускоряет разработку, но часто приводит к сложному, плохо понятному коду, что создает долгосрочные проблемы с поддержкой и увеличивает "долг понимания".
• Мнения разделились: одни считают проблему поддержки LLM-кода преувеличенной или временной, другие видят в ней фундаментальный сдвиг, усугубляющий существующие проблемы с legacy-кодом.
• Предлагаются стратегии работы: строгий ревью, использование LLM только для тривиальных задач/черновиков, написание тестов и документации, либо полное принятие модели "черного ящика".
• Многие ожидают, что будущие LLM смогут сами понимать и поддерживать сгенерированный код, что изменит роль разработчика на более высокоуровневую.
• Параллель с прошлыми проблемами (офшорная разработка, копипаст с Stack Overflow), но масштаб и скорость генерации LLM создают беспрецедентные вызовы.

Open Printer — это струйный принтер с открытым исходным кодом, созданный парижским стартапом Open Tools. Он использует популярные картриджи HP 63, но без DRM-блокировок, что позволяет применять любые совместимые чернила от сторонних производителей. Конструкция модульная и легко ремонтируемая, с использованием стандартных механических компонентов.

Устройство поддерживает печать на рулонной бумаге, что даёт гибкость в выборе форматов: встроенный резак создаёт листы А4 или позволяет печатать длинные материалы, например баннеры. Запуск планируется через краудфандинговую кампанию, что делает его аналогом Fairphone в мире принтеров — открытым, доступным и свободным от ограничений крупных брендов.

• Использование лицензии Creative Commons BY-NC-SA 4.0 вызывает критику, так как она не соответствует определению открытого исходного кода и ограничивает коммерческое использование и распространение.
• Дизайн принтера и его практичность подвергаются сомнению: отсутствие лотка для бумаги, поддержка только рулонной подачи, невозможность печати на конвертах или этикетках, а также отсутствие дуплексной печати.
• Высказываются опасения, что проект может быть «vaporware» (нереализованным концептом), так как нет демонстрационных видео работы устройства и отсутствуют базовые технические характеристики, например, скорость печати.
• Отмечается, что принтер использует старые печатающие головки HP от моделей 2014 года, что может быть связано с доступностью документации и патентными ограничениями.
• Многие пользователи выражают скептицизм относительно необходимости собственного принтера, предпочитая лазерные модели из-за их надежности и отсутствия проблем с засыханием чернил, либо вообще обходясь без личного принтера.

BlueSky автоматически блокирует контент для взрослых, используя алгоритмы для пометки аккаунтов и скрытия их постов. Это вызывает споры, поскольку система может ошибочно цензурировать легальный контент, включая искусство, образовательные материалы и аккаунты ЛГБТК+. Пользователи в ЕС теоретически могут использовать GDPR для обхода этих блокировок, запрашивая исправление неточных меток как ошибочных персональных данных.

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

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

Автор блога удаляет Disqus из-за ужасного качества встраиваемой рекламы. Изначально он почти забыл о её появлении, так как Disqus обещал ненавязчивый подход, но при отключении блокировщика обнаружил криво оформленные и мошеннические объявления, портящие чистый, минималистичный дизайн сайта.

Из-за использования Pi-hole и VPN автор годами не сталкивался с рекламой и осознал, насколько плох опыт обычных пользователей. Disqus не только ухудшал впечатление от блога, но и монетизировал чужие данные, нарушая приватность. Вместо комментариев он предлагает связаться через GitHub или Twitter, но открыт к рекомендациям приватных или самохостовых систем.

• Пользователи критикуют Disqus за обилие рекламы, трекеров, низкую производительность и сложность борьбы со спамом, что заставляет искать альтернативы.
• Предлагаются различные решения для комментариев: самохостинг (Isso, Remark42, Comentario), использование сторонних сервисов (GitHub Discussions через Giscus, Hyvor Talk), интеграция с федеративными платформами (Mastodon, Bluesky) или полный отказ от комментариев.
• Распространена точка зрения, что содержательные обсуждения ушли в соцсети (HN, Reddit) и Fediverse, а комментарии на блогах часто не стоят усилий по поддержке и модерированию.
• Многие предпочитают минималистичные подходы: запрос комментариев по email, кросс-постинг статей в сообщества для обсуждения или простое удаление функционала комментариев.
• Подчёркивается важность контроля над данными, производительности и приватности при выборе системы комментариев, а также сложность борьбы со спамом без централизованных решений.

Файловая система Bcachefs полностью удалена из основного ядра Linux, начиная с версии 6.18. Это решение связано с тем, что разработка переместилась во внешний модуль DKMS, что сделало встроенную версию устаревшей и потенциально вызывающей путаницу. Ранее, в релизе 6.17, система уже была помечена как внешне поддерживаемая.

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

• Пользователи выражают разочарование удалением bcachefs из основной ветки ядра Linux из-за конфликта между его разработчиком и сообществом.
• Обсуждаются технические последствия перехода на DKMS-модуль: необходимость настройки для Secure Boot, потенциальные проблемы с будущими обновлениями ядра.
• Участники сравнивают bcachefs с другими файловыми системами (Btrfs, ZFS), отмечая его потенциал, но критикуя текущую производительность и стабильность.
• Основная причина удаления видится не в технических недостатках, а в неспособности сопровождающего соблюдать правила разработки ядра.
• Высказываются надежды на возврат bcachefs в основную ветку в будущем с другим сопровождающим и после достижения большей стабильности.

В задаче Google CTF 2025 webz исследуется уязвимость в патче Google-zlib, который увеличивает размер таблицы Хаффмана и убирает проверки на переполнение. Это позволяет обойти защиту от oversubscription и incomplete set, что ведёт к использованию неинициализированной памяти в таблице.

Уязвимость проявляется в функции inflate_fast, где неверно построенная таблица Хаффмана приводит к чтению за пределами буфера или использованию мусорных данных. Это позволяет перезаписать указатели и выполнить код, манипулируя сжатыми данными. Эксплуатация требует точного контроля над структурой Deflate-блока для управления содержимым таблицы.

• Обсуждается уязвимость в модифицированной версии zlib, созданной специально для CTF-задачи Google, а не в основной библиотеке.
• Участники отмечают сложность и искусственный характер задач Google CTF, но предлагают ресурсы для обучения и тренировки.
• Проводятся параллели между этой уязвимостью и ранее обнаруженной уязвимостью в WebP.
• Подчёркивается, что ошибку можно быстро найти с помощью фаззинга, без необходимости привлечения ИИ.
• Уточняется, что заголовок исходной статьи содержал пометку "[CTF]", указывающую на соревновательный контекст.

Определить местоположение пользователя по IP-адресу в интернете — сложная задача, поскольку интернет-адреса не несут встроенной географической информации. Для создания геолокационных баз данных, которые связывают IP-адреса со странами или координатами, приходится решать множество проблем: от выбора формата представления местоположения (широта/долгота или коды стран) до определения самих понятий «страна» и её границ. Здесь помогают стандарты вроде ISO 3166 и данные ООН, но даже они не идеальны.

Такие базы критически важны для борьбы с кибератаками, защиты авторских прав и статистического анализа, например, для сравнения числа интернет-пользователей по странам. Однако источники данных разнятся: коммерческие провайдеры вроде Maxmind предлагают платные услуги, а реестры RIR (региональных интернет-регистраторов) часто неточны, поскольку фиксируют страну регистрации владельца адресов, а не реальное место их использования. Это особенно проблематично для глобальных сетей, где адреса развёрнуты в нескольких странах.

• Критика практик геолокации пользователей интернета без их согласия из-за рисков слежки и ограничения свобод
• Обсуждение проблем регулирования Starlink, который обходит национальные ограничения через реселлеров и роуминг
• Примеры использования IP-геолокации для борьбы с мошенничеством и её ограниченной точности
• Споры о доверии к технологическим компаниям vs. правительствам в вопросах регулирования и контроля данных
• Технические сложности точного определения местоположения через IP из-за прокси, VPN и схем назначения адресов

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

Лицензия имеет сильный copyleft, предотвращающий присвоение улучшенных версий ПО третьими сторонами. EUPL совместима с другими популярными лицензиями, такими как GPL, через специальное положение о совместимости, позволяющее комбинировать код под разными лицензиями. Хотя изначально предназначена для госсектора, она может использоваться любым правообладателем ПО.

• EUPL моделируется после GPLv3, закрывает SaaS-лазейку, но исключает положения о тивоизации и DRM, а также явно определяет юрисдикцию ЕС.
• Лицензия фокусируется на юридической интероперабельности в ЕС, имеет список совместимых лицензий, но её совместимость с GPL вызывает споры о потенциальном релизайсинге.
• EUPL мало распространена, воспринимается как политический/правовой компромисс, а не идеологическое заявление, и её практическая полезность ставится под сомнение.
• Некоторые участники обсуждают выбор между EUPL и AGPLv3, отмечая модификации EUPL и её применимость вне ЕС.
• Поднимаются вопросы о лицензиях с ограничительными клаузами (например, против оружия или ископаемого топлива), но отмечается их непопулярность из-за неоднозначности.