Hacker News Digest

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

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

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

Владельцы Jeep Wrangler 4xe столкнулись с критическим сбоем после установки обновления ПО, выпущенного в пятницу. Обновление, предназначенное для информационно-развлекательной системы Uconnect, привело к отказу силовой установки во время движения. Некоторые водители оказались заблокированы на дорогах общего пользования, включая случаи на высоких скоростях.

Производитель быстро отозвал обновление, но для некоторых владельцев было уже поздно. Владельцы, ещё не установившие обновление, получили указание игнорировать его. К понедельнику Jeep выпустил патч, исправляющий проблему, однако детали о количестве затронутых автомобилей или инцидентов на дорогах не раскрываются.

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

• Jeep 4xe внезапно умер в гараже после обновления, а Stellantis молчит; владельцы жалуются на полное отсутствие официального ответа.
• Пользователи обсуждают, что OTA-обновления вообще не должны затрагивать критические системы, а уязвимость, которая позволила это произойти, должна была бы обнаружена и исправлена.
• Сообщество также поднимает вопрос, что если автопроизводитель не может гарантировать безопасность обновлений, то он должен быть обязан предоставлять физическую изоляцию инфотейнмента от ECU.
• Несколько человек упоминают, что владельцы 4xe и других моделей Stellantis уже не первый раз сталкиваются с проблемами после обновлений, но это первый случай, когда обновление вывело из строя само транспортное средство.
• Некоторые комментаторы поднимают вопрос, почему вообще допускается, чтобы обновления могли бы выводить из строя критические системы, и почему не предусмотрен механизм отката.

В 1980 году выпускники Университета Ватерлоо Гордон Белл и Дэн Додж основали Quantum Software Systems и начали разработку операционной системы QUNIX (позже переименованной в QNX). Их вдохновил опыт работы с Thoth — реальной ОС с синхронной передачей сообщений, написанной на высокоуровневых языках. Первая версия QUNIX 0.1 работала на самосборном компьютере с процессором Motorola 6809, а с появлением IBM PC в 1981 году они адаптировали систему под эту платформу.

QUNIX сочетала черты UNIX и CP/M: вместо стандартных каталогов вроде /bin использовались /cmds, /config, /sys. Команды отличались — например, help вместо man, task вместо ps. Это была первая микроядерная ОС для PC, ориентированная на надёжность в промышленных и коммуникационных системах. Интересная деталь: в ранних маркетинговых материалах график на мониторе был физически приклеен из-за отсутствия инструментов редактирования фото.

• Участники делятся личным опытом использования QNX в образовании (компьютеры ICON), робототехнике, на BlackBerry и в различных встраиваемых системах, отмечая её надёжность и элегантность.
• Многие вспоминают впечатляющую малую занимаемую память QNX и её демо-версию на дискетах, которая включала полноценную ОС с графическим интерфейсом и сетью.
• Обсуждаются сильные стороны ОС: изоляция процессов, реальное время и сетевая прозрачность, но также отмечаются недостатки, такие как накладные расходы на передачу сообщений.
• Упоминается использование QNX в индустрии (автомобильные инфотейнмент-системы VW/Audi, Skytrain в Ванкувере) и её влияние на дальнейшую карьеру в IT.
• Высказывается сожаление о упадке платформы и интерес к возможному открытию её исходного кода, а также ностальгия по эстетике интерфейса Photon.

Миниатюрная библиотека sj.h для парсинга JSON весит всего 500 строк кода и использует единственный заголовочный файл. Она спроектирована для минимализма и эффективности, поддерживая базовые операции: разбор строк, чисел, булевых значений, массивов и объектов.

Библиотека не требует динамического выделения памяти, что делает её идеальной для встраиваемых систем и сред с ограниченными ресурсами. Её API интуитивен — всего несколько функций для доступа к данным, что снижает порог входа. Практический плюс: легко интегрируется в существующие C-проекты без зависимостей.

• Обсуждаются достоинства библиотеки автора: однофайловые решения на ANSI C/Lua с фокусом на простоту, удобный интерфейс и хорошую документацию.
• Отмечаются потенциальные проблемы безопасности и корректности: отсутствие проверок на переполнение целых чисел, возможное неопределённое поведение, слабая валидация JSON.
• Поднимается вопрос о целесообразности использования: обсуждаются нишевые применения (например, embedded), недостатки для продакшена и альтернативные библиотеки.
• Упоминается необходимость тестирования на соответствие стандарту (конформность) и handling edge cases.
• Обсуждается философия подобных минималистичных библиотек: свобода от избыточной сложности ценой отказа от безопасности и обработки всех крайних случаев.

32-битные системы устарели, но ядро всё ещё их поддерживает из-за старого «железа» и ПО.
Arnd Bergmann: новые продукты уже 20 лет выходят на 64-битных платформах; встраиваемые устройства постепенно переходят с armv7 (32-бит) на armv8 (64-бит).

• Arm: 90 % встраиваемых систем; лишь три старые архитектуры до-armv7 ещё можно купить, но ядро держит десяток выведенных из производства. Поддержку можно выбрасывать «по половинам», когда исчезнут пользователи.
• Другие 32-битные архитектуры (arc, microblaze, nios2, openrisc, rv32, sparc/leon, xtensa) вытесняются RISC-V.
• nommu (armv7-m, m68k, superh, xtensa) никто не выпускает, их держат лишь ради существующих систем.

Для несовместимых 32-битных приложений — запуск 32-битного userspace на 64-битном ядре: экономит память, не требует 32-битного ядра.

Боль разработчиков:

• Высокая память (highmem) усложняет mm-подсистему; нужна, когда физической памяти > ~800 МБ.
• Ядро пока держит 32-битные машины до 16 ГБ, но таких почти нет; 4 ГБ встречаются (Chromebook), 2 ГБ — чаще, но «глупо»: память дороже CPU.

• Участники обеспокоены удалением поддержки nommu/32-бит: это уменьшает свободу, лишает возможности запускать Linux на старом или простом железе и делает ядро похожим на «дорожную карту» Apple/Windows.
• Некоторые предлагают форк «Linux Legacy» или переход на NetBSD/OpenBSD, которые по-прежнему поддерживают старые архитектуры.
• Для встраиваемых устройств без MMU считают более подходящими Zephyr, NuttX или Contiki, а не полноценный Linux.
• Поддержка big-endian почти мертва, но сохранится, пока IBM вкладывается в s390x.
• Старые ядра и LTS-дистрибутивы ещё десятилетие обеспечат безопасность и работу выброшенного железа.