Powerless F1 drivers frustrated by Bahrain F1 software glitch 💬 Длинная дискуссия
На Гран-при Бахрейна произошел масштабный сбой в программном обеспечении FIA, который лишил пилотов доступа к критически важным данным во время гонки. Из-за ошибки в системе отображения информации на рулевых колесах и в боксах команды не могли видеть текущие позиции, интервалы между машинами, состояние шин и предупреждения о желтых флагах. Пилоты описывали ситуацию как «ужасную и полностью неприемлемую», отмечая, что они фактически гонялись вслепую, полагаясь только на интуицию и ограниченную связь с инженерами. Некоторые сравнивали это с вождением в условиях полной потери ситуационной осведомленности, что создавало серьезные риски безопасности.
Сбой затронул практически все команды и продолжался значительную часть гонки, прежде чем инженерам FIA удалось восстановить работу системы через резервные каналы. Пилоты, включая Ландо Норриса и Шарля Леклера, открыто критиковали FIA за недостаточную надежность критически важных систем, подчеркивая, что такие сбои недопустимы на уровне Формулы 1. Инцидент поднял вопросы о резервировании и тестировании программного обеспечения, используемого в гонках, и может привести к пересмотру протоколов обеспечения бесперебойной работы телеметрии и информационных систем в будущих этапах чемпионата.
Комментарии (158)
Все машины Формулы‐1 используют одинаковый ECU‐хардвар — TAG700 от McLaren Applied (ранее Motion Applied). Фирменное ПО должно соответствовать правилам FIA; команды могут менять только параметры, а не ядро прошивки. Обновления прошивки применяются между сессиями, часто через флеш‐накопитель или кабель в гараже во время красного флага, без длительного лабораторного тестирования. Сбой в Бахрейне, вероятно, вызван изменением конфигурации или отключением безопасных ограничений, а не полной заменой кода, и усугублен недостаточным тестированием в дождевых условиях. Маленькие команды имеют ограниченные ресурсы для тестирования и полагаются на ПО, предоставляемое FIA, что повышает риск ошибок. Разработчики ПО в мотоспорте часто работают без строгих процессов, что приводит к более низкому качеству кода по сравнению с автомобильной или промышленной отраслью. F1‐карты рассматриваются как прототипы: каждый Гран‐при отличается небольшими изменениями в аппаратуре и ПО, поэтому баги появляются регулярно. Поставщик ECU — Motion Applied (ранее McLaren Applied Technologies), ПО поставляется FIA. Ilmore не является поставщиком ECU в F1.
Bug Blindness 🔥 Горячее 💬 Длинная дискуссия
Многие люди не замечают баги в ПО, потому что привыкли игнорировать мелкие сбои — это «слепота к багам». Программисты, вроде автора, видят их повсюду: от неинтуитивных обходных путей до полного неработающего функционала. Часто то, что кажется «нормальным» для разработчиков, для обычных пользователей — неприемлемый опыт, который отталкивает их от продукта. Автор отмечает, что его наблюдения редко оказываются аномалией: когда продукт падает после запуска, пользователи сталкиваются с теми же проблемами, которые он заметил задолго до релиза.
Даже крупные сервисы — Google, Bing, Kagi — показывают плохие результаты поиска, заполненные спамом и мошенническими сайтами. Автор не считает это «серьёзным» багом в строгом смысле, но для пользователя это уже неработающий инструмент. Аналогично, Tumblr, несмотря на заявления о «решённой модерации», был платформой, где система репостов намеренно провоцировала конфликты — и это игнорировалось внутри компании. Автор подчёркивает: если продукт кажется сломанным при обычном использовании, он, скорее всего, действительно сломан. Современные LLM-модели подтверждают: баги воспроизводятся не только у «необычных» пользователей, но и у симулированных «нормальных».
Комментарии (259)
Обсуждение раскрывает, почему баги остаются незамеченными: это следствие эволюционной фильтрации повторяющихся сигналов, нормализации отклонений, различий в мышлении разработчиков и пользователей, а также системных проблем в организации разработки. Разработчики не видят баги, потому что их модель мышления совпадает с моделью системы; у пользователей модели нет — они просто добиваются результата. При постоянных изменениях системы пользователи адаптируются и используют обходные пути вместо того, чтобы разбираться в её логике. Мозг привычно игнорирует повторяющиеся сигналы, поэтому хронические баги перестают восприниматься как проблема. Пользователи без технического бэкграунда часто не отличают сбой от штатного поведения. Качество ПО оценивается по порогу приемлемости: при низком пороге баги игнорируются, при высоком — вызывают сильное раздражение. Спорные моменты: некоторые считают некорректным называть плохие результаты поиска багами, сравнивая это с названием плохой книги «багом издательства». Часть пользователей Kagi защищает продукт, и это может быть связано с эффектом вложенных средств — особенно при наличии бесплатных альтернатив. Дополнительные факторы: пользователи применяют «защитное поведение» — избегают длинных путей, нестандартных Unicode-имён, не используют папку «My Documents». Разработчики с опытом QA становятся сверхчувствительными к сбоям, что мешает им создавать продукты. В крупных корпоративных системах (Blackboard, Epic, SharePoint) заказчики и пользователи — разные люди, и заказчики не мотивированы улучшать пользовательский опыт, поэтому баги воспринимаются как норма. ИИ-агенты хуже людей замечают дефекты в собственном выводе, так как оценивают успех по своим метрикам, а не по реальному опыту пользователя, — человеческий ревью остаётся ключевым навыком. Многие разработчики стремятся заставить программу выполнить задачу, а не сделать так, чтобы она не могла её не выполнить, — это ведёт к провалу при первом контакте с пользователем. Пользователи часто не могут сообщить о багах из-за отсутствия каналов обратной связи и игнорирования репортов, включая open-source. Люди, любящие продукт, игнорируют его недостатки из-за эффекта обратной связи — критика воспринимается как угроза. Совет: LLM стоит использовать не для ускорения разработки, а для исправления багов и улучшения пользовательского опыта.
Ton Roosendaal to step down as Blender chairman and CEO 🔥 Горячее
Тон Росендал покидает пост председателя и генерального директора Blender с 1 января 2026 года. Новость была объявлена во время ключевого выступления на ежегодной конференции Blender.
Росендал — создатель открытого 3D-программного обеспечения и его публичное лицо на протяжении трёх десятилетий — передаст свои роли нынешнему операционному директору Blender Франческо Сидди. Сам Росендал перейдёт в новый наблюдательный совет Фонда Blender.
В совет также войдут Сергей Шарыбин (руководитель разработки), Далай Фелинто (руководитель продукта) и Фиона Коэн (руководитель операционной деятельности).
«Мы готовились к этому с 2019 года, — сказал Росендал. — Я горжусь, что вокруг меня такая талантливая молодая команда, которая выведет наш свободный проект в следующее десятилетие».
Комментарии (70)
- Тон Росендал — личный герой и легенда для многих, вдохновивший целое поколение 3D-художников и аниматоров.
- Blender прошёл путь от непопулярного софта в начале 2000-х до инструмента, изменившего индустрию и ставшего конкурентом проприетарным решениям.
- Его стратегическое лидерство и переход на открытый код в 2002 году стали ключевым подарком для сообщества и образцом успеха FOSS.
- Тон известен как блестящий стратег, великодушный человек и лидер, который доверял сообществу и не микроменеджировал развитие проекта.
- Сообщество Blender отмечает его огромный вклад в создание не только мощного ПО, но и невероятно supportive и творческой экосистемы.
- Многие выражают благодарность за его работу и надеются, что проект продолжит thrive под новым руководством.
- Его наследие — это доказательство того, что открытое ПО может быть профессиональным, доступным и менять мир к лучшему.