Hacker News Digest

Ryan Fleury в своём блоге Digital Grove рассуждает о том, что современные процессоры уже давно многоядерны, но большинство программистов всё ещё пишут однопоточный код, упуская до 90% вычислительной мощности. Он приводит пример: сумма элементов массива может быть распараллелена на 4 ядра, но в итоге выигрыш в 3.2 раза превращается в проигрыш в 1.3 раза из-за накладных расходов на синхронизацию и кэш-коэффициенты. Автор приходит к выводу, что надо не "добавлять" многопоточность в специфические случаи, а с самого начала писать весь код как будто он многопоточен, и тогда не будет никаких "особых случаев".

• Обсуждение показало, что современные языки и фреймворки всё ещё не решают фундаментальную проблему — как писать код, который по-настоящему использует многоядерные CPU.
• Участники подчеркнули, что большинство программистов не имеют ни инструментов, ни культуры для эффективного использования параллелизма.
• Были упомянуты такие концепции как "неявный параллелизм" и "автоматическое распараллеливание", но никто не смог привести примеры их практического применения.
• Обсуждение также затронуло вопрос о том, что большинство задач пользователя не требуют параллельного выполнения, и что производительность часто ограничена не столько CPU, сколько IO или GPU.

Автор перешёл с HTMX на Datastar, потому что последний убирает две проблемы: размер кода и сложность синхронизации фронтенда с бэкендом. Он показывает, что на практике это сокращает код на 60-70% и убирает необходимость вручную управлять состоянием на клиенте. Datastar заставляет сервер описывать, какие элементы и как должны обновляться, и это упрощает логику. Пример: вместо 3-4 атрибутов HTMX достаточно одного data-on-click. Это также убирает необходимость вручную следить за событиеми и состоянием, потому что вся логика находится в одном месте.

• Обсуждение в основном вращается вокруг сравнения Datastar и HTMX, где участники делятся опытом, спорят о том, какие фичи действительно нужны, и обсуждают, какие из фреймворков лучше подходят для разных сценариев использования.
• Несколько участников подчеркивают, что Datastar требует оплаты за ряд базовых функций, что вызывает сомнения в ценности продукта для open-source сообщества.
• Некоторые комментаторы высказывают, что Datastar и HTMX имеют разные подходы к обновлению контента: Datastar использует Server-Sent Events, в то время как HTMX использует обычные HTTP-запросы.
• Участники обсуждают, что Datastar требует больше кода на стороне сервера, в то время как HTMX позволяет легко обновлять различные части страницы без дополнительного кода.
• Некоторые комментаторы высказывают, что Datastar и HTMX имеют разные подходы к обновлению контента: Datastar использует Server-Sent Events, в то время как HTMX использует обычные HTTP-запросы.

Исследователи из Google DeepMind и Университета Монреаля показали, что современные LLM не используют формальное рассуждение, а вместо этого ищут решение в пространстве возможных решений. Это открытие ставит под сомнение саму идею, что масштабные языковые модели "рассуждают" как люди.

Команда обучила модель, которая решает задачи, используя цепочку мыслей, и другую, которая не использует. Оказалось, что вторая модель достигает такой же точности, как и первая. Это показывает, что LLM не используют формальное рассуждение, а вместо этого ищут решение в пространстве возможных решений. Исследование также показало, что модели становятся менее уверенными в своих ответах, когда задачи становятся сложнее.

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

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

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

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