Hacker News Digest

Тег: #software

Постов: 3

Powerless F1 drivers frustrated by Bahrain F1 software glitch (motorsport.com) 💬 Длинная дискуссия

На Гран-при Бахрейна произошел масштабный сбой в программном обеспечении FIA, который лишил пилотов доступа к критически важным данным во время гонки. Из-за ошибки в системе отображения информации на рулевых колесах и в боксах команды не могли видеть текущие позиции, интервалы между машинами, состояние шин и предупреждения о желтых флагах. Пилоты описывали ситуацию как «ужасную и полностью неприемлемую», отмечая, что они фактически гонялись вслепую, полагаясь только на интуицию и ограниченную связь с инженерами. Некоторые сравнивали это с вождением в условиях полной потери ситуационной осведомленности, что создавало серьезные риски безопасности.

Сбой затронул практически все команды и продолжался значительную часть гонки, прежде чем инженерам FIA удалось восстановить работу системы через резервные каналы. Пилоты, включая Ландо Норриса и Шарля Леклера, открыто критиковали FIA за недостаточную надежность критически важных систем, подчеркивая, что такие сбои недопустимы на уровне Формулы 1. Инцидент поднял вопросы о резервировании и тестировании программного обеспечения, используемого в гонках, и может привести к пересмотру протоколов обеспечения бесперебойной работы телеметрии и информационных систем в будущих этапах чемпионата.

by llm_nerd • 05 октября 2026 г. в 01:54 • 190 points

Оригинал • HN

#f1#fia#motorsport#software#telemetry

Комментарии (158)

Все машины Формулы‐1 используют одинаковый ECU‐хардвар — TAG700 от McLaren Applied (ранее Motion Applied). Фирменное ПО должно соответствовать правилам FIA; команды могут менять только параметры, а не ядро прошивки. Обновления прошивки применяются между сессиями, часто через флеш‐накопитель или кабель в гараже во время красного флага, без длительного лабораторного тестирования. Сбой в Бахрейне, вероятно, вызван изменением конфигурации или отключением безопасных ограничений, а не полной заменой кода, и усугублен недостаточным тестированием в дождевых условиях. Маленькие команды имеют ограниченные ресурсы для тестирования и полагаются на ПО, предоставляемое FIA, что повышает риск ошибок. Разработчики ПО в мотоспорте часто работают без строгих процессов, что приводит к более низкому качеству кода по сравнению с автомобильной или промышленной отраслью. F1‐карты рассматриваются как прототипы: каждый Гран‐при отличается небольшими изменениями в аппаратуре и ПО, поэтому баги появляются регулярно. Поставщик ECU — Motion Applied (ранее McLaren Applied Technologies), ПО поставляется FIA. Ilmore не является поставщиком ECU в F1.

Bug Blindness (danluu.com) 🔥 Горячее 💬 Длинная дискуссия

Многие люди не замечают баги в ПО, потому что привыкли игнорировать мелкие сбои — это «слепота к багам». Программисты, вроде автора, видят их повсюду: от неинтуитивных обходных путей до полного неработающего функционала. Часто то, что кажется «нормальным» для разработчиков, для обычных пользователей — неприемлемый опыт, который отталкивает их от продукта. Автор отмечает, что его наблюдения редко оказываются аномалией: когда продукт падает после запуска, пользователи сталкиваются с теми же проблемами, которые он заметил задолго до релиза.

Даже крупные сервисы — Google, Bing, Kagi — показывают плохие результаты поиска, заполненные спамом и мошенническими сайтами. Автор не считает это «серьёзным» багом в строгом смысле, но для пользователя это уже неработающий инструмент. Аналогично, Tumblr, несмотря на заявления о «решённой модерации», был платформой, где система репостов намеренно провоцировала конфликты — и это игнорировалось внутри компании. Автор подчёркивает: если продукт кажется сломанным при обычном использовании, он, скорее всего, действительно сломан. Современные LLM-модели подтверждают: баги воспроизводятся не только у «необычных» пользователей, но и у симулированных «нормальных».

by davidmckenna • 30 августа 2026 г. в 00:21 • 387 points

Оригинал • HN

#bug#llm#software

Комментарии (259)

Обсуждение раскрывает, почему баги остаются незамеченными: это следствие эволюционной фильтрации повторяющихся сигналов, нормализации отклонений, различий в мышлении разработчиков и пользователей, а также системных проблем в организации разработки. Разработчики не видят баги, потому что их модель мышления совпадает с моделью системы; у пользователей модели нет — они просто добиваются результата. При постоянных изменениях системы пользователи адаптируются и используют обходные пути вместо того, чтобы разбираться в её логике. Мозг привычно игнорирует повторяющиеся сигналы, поэтому хронические баги перестают восприниматься как проблема. Пользователи без технического бэкграунда часто не отличают сбой от штатного поведения. Качество ПО оценивается по порогу приемлемости: при низком пороге баги игнорируются, при высоком — вызывают сильное раздражение. Спорные моменты: некоторые считают некорректным называть плохие результаты поиска багами, сравнивая это с названием плохой книги «багом издательства». Часть пользователей Kagi защищает продукт, и это может быть связано с эффектом вложенных средств — особенно при наличии бесплатных альтернатив. Дополнительные факторы: пользователи применяют «защитное поведение» — избегают длинных путей, нестандартных Unicode-имён, не используют папку «My Documents». Разработчики с опытом QA становятся сверхчувствительными к сбоям, что мешает им создавать продукты. В крупных корпоративных системах (Blackboard, Epic, SharePoint) заказчики и пользователи — разные люди, и заказчики не мотивированы улучшать пользовательский опыт, поэтому баги воспринимаются как норма. ИИ-агенты хуже людей замечают дефекты в собственном выводе, так как оценивают успех по своим метрикам, а не по реальному опыту пользователя, — человеческий ревью остаётся ключевым навыком. Многие разработчики стремятся заставить программу выполнить задачу, а не сделать так, чтобы она не могла её не выполнить, — это ведёт к провалу при первом контакте с пользователем. Пользователи часто не могут сообщить о багах из-за отсутствия каналов обратной связи и игнорирования репортов, включая open-source. Люди, любящие продукт, игнорируют его недостатки из-за эффекта обратной связи — критика воспринимается как угроза. Совет: LLM стоит использовать не для ускорения разработки, а для исправления багов и улучшения пользовательского опыта.

Ton Roosendaal to step down as Blender chairman and CEO (cgchannel.com) 🔥 Горячее

Тон Росендал покидает пост председателя и генерального директора Blender с 1 января 2026 года. Новость была объявлена во время ключевого выступления на ежегодной конференции Blender.

Росендал — создатель открытого 3D-программного обеспечения и его публичное лицо на протяжении трёх десятилетий — передаст свои роли нынешнему операционному директору Blender Франческо Сидди. Сам Росендал перейдёт в новый наблюдательный совет Фонда Blender.

В совет также войдут Сергей Шарыбин (руководитель разработки), Далай Фелинто (руководитель продукта) и Фиона Коэн (руководитель операционной деятельности).

«Мы готовились к этому с 2019 года, — сказал Росендал. — Я горжусь, что вокруг меня такая талантливая молодая команда, которая выведет наш свободный проект в следующее десятилетие».

by cma • 17 сентября 2025 г. в 16:49 • 349 points

Оригинал • HN

#3d#animation#blender#foss#opensource#software

Комментарии (70)

  • Тон Росендал — личный герой и легенда для многих, вдохновивший целое поколение 3D-художников и аниматоров.
  • Blender прошёл путь от непопулярного софта в начале 2000-х до инструмента, изменившего индустрию и ставшего конкурентом проприетарным решениям.
  • Его стратегическое лидерство и переход на открытый код в 2002 году стали ключевым подарком для сообщества и образцом успеха FOSS.
  • Тон известен как блестящий стратег, великодушный человек и лидер, который доверял сообществу и не микроменеджировал развитие проекта.
  • Сообщество Blender отмечает его огромный вклад в создание не только мощного ПО, но и невероятно supportive и творческой экосистемы.
  • Многие выражают благодарность за его работу и надеются, что проект продолжит thrive под новым руководством.
  • Его наследие — это доказательство того, что открытое ПО может быть профессиональным, доступным и менять мир к лучшему.