Hacker News Digest

Новый iPhone Air, самый тонкий смартфон Apple (5,64 мм), оказался неожиданно ремонтопригодным. Вместо традиционной компоновки с наложенными друг на друга компонентами Apple разместила аккумулятор в центре, а материнскую плату — над ним, создав «плоское дерево разборки». Это упрощает доступ к ключевым деталям, сокращает время ремонта и снижает риск повреждения других компонентов — подход, ранее успешно реализованный Samsung в Galaxy S25 Edge и компанией Framework в ноутбуках.

Аккумулятор ёмкостью 12,26 Вт·ч вызывает вопросы о долговечности, но его замена остаётся простой благодаря продуманной конструкции. Устройство также лишено некоторых элементов, как второй динамик и дополнительная камера, что уменьшает сложность и количество точек отказа. Инженерное решение не только обеспечивает лёгкость ремонта, но и снижает риск деформации корпуса, избегая проблем прошлых тонких моделей.

• Обсуждается технология 3D-печати титановых деталей в iPhone Air, предположительно лазерное спекание или струйное напыление связующего, что необычно для массового производства.
• Отмечается высокая прочность и ремонтопригодность устройства, включая неожиданную устойчивость к изгибу и давление в ~100 кг для повреждения экрана.
• Высказываются предположения о будущем Apple, включая складной iPhone из двух тонких половин и улучшения техпроцесса SoC, тандемных OLED и батарей.
• Поднимаются вопросы о сериализации запчастей, необходимости одобрения Apple для замены батареи и соответствии новым EU-директивам о праве на ремонт.
• Критикуется камера с выступом, выражается ностальгия по старым текстово-графическим разборам iFixit и обсуждается геополитика поставок титана.

Amazon закрывает свою программу коминглинга, которая позволяла смешивать одинаковые товары от разных продавцов под одним штрихкодом. Эта практика, хотя и ускоряла доставку и экономила место на складах, годами вызывала жалобы брендов из-за подделок и просроченных товаров, попадавших к покупателям. Например, Johnson & Johnson временно уходила с платформы в 2013 году, опасаясь за свою репутацию.

Решение, объявленное на конференции Accelerate, было встречено аплодисментами продавцов. Оно отражает стремление Amazon усилить защиту брендов и улучшить отслеживаемость продукции, что может повысить доверие к маркетплейсу.

• Пользователи сообщают о многократных случаях получения контрафактных и некачественных товаров через Amazon, особенно в рамках подписки Subscribe & Save.
• Многие выражают недоверие к решению Amazon, считая его запоздалым и мотивированным экономическими причинами, а не заботой о клиентах.
• В качестве реакции на проблему часть пользователей сократила покупки на Amazon, переключившись на розничные магазины или покупки напрямую у брендов.
• Обсуждается, что отказ от смешивания inventory может улучшить опыт покупателей, но некоторые сомневаются в реальных изменениях и исполнении.
• Поднимается вопрос о глобальности изменений и различиях в качестве обслуживания в разных регионах (например, amazon.de vs amazon.co.jp).

Многие библиотеки в экосистеме JavaScript стали избыточно сложными из-за попыток обработать все возможные крайние случаи, даже те, что на практике почти не встречаются. Например, функция clamp, предназначенная для ограничения чисел, превращается в монстра, проверяющего строки, валидирующего типы и значения, что приводит к появлению микробиблиотек вроде is-number с 90 млн загрузок в неделю. Это результат плохого технического дизайна: вместо чёткого определения ожидаемых входных данных разработчики добавляют слои проверок для гипотетических сценариев.

Правильный подход — проектировать функции под конкретные типы данных, оставляя валидацию значений на усмотрение вызывающей стороны. Библиотеки вроде is-arrayish или pascalcase, принимающие разнородные входы, лишь увеличивают сложность и зависимости без реальной пользы. Стоит вернуться к простоте: в большинстве случаев достаточно встроенных методов языка, а специализированные решения нужны только для узких задач, а не как стандарт.

• Обсуждение критикует избыточное использование зависимостей в JavaScript/TypeScript для простых задач, таких как проверка типов, что ведет к раздуванию экосистемы.
• Участники связывают проблему с историческими особенностями JavaScript: отсутствием строгой типизации и богатой стандартной библиотеки в прошлом.
• Поднимается вопрос о дизайне контрактов функций: следует ли валидировать входные данные внутри функции или возлагать эту ответственность на вызывающую сторону.
• Отмечается культурное различие между сообществами: в Python принята модель "согласованных взрослых", а в JS — оборонительное программирование.
• Обсуждается роль статической типизации (TypeScript) и стандартных библиотек как способа уменьшить потребность в микро-пакетах для проверок.

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

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

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

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

На ядрах Linux версии 4.0+ алгоритмы свопа значительно улучшены, уменьшая риски избыточного вытеснения страниц. Для SSD использование свопа практически эквивалентно по задержкам работе с файловыми страницами, а на HDD оправдано снижение параметра vm.swappiness. Важно отметить, что отключение свопа не предотвращает проблем в условиях нехватки памяти — оно лишь смещает их в другую область, не решая коренную проблему.

• Обсуждение затрагивает практический опыт использования swap: от успешных кейсов с распределенными системами и Raspberry Pi до проблем с производительностью при нехватке памяти.
• Участники спорят о необходимости swap: одни считают его полезным для вытеснения неактивных страниц, другие — вредным, продлевающим период нестабильности системы при нехватке памяти.
• Критикуется работа OOM killer в Linux за непредсказуемость и предлагаются альтернативы (earlyoom, systemd-oomd, ручной вызов через SysRq).
• Поднимается вопрос о проектировании программ: следует ли избегать аллокации большого объема неиспользуемой памяти или полагаться на swap и перезапуски.
• Отмечается разница в поведении ядер Linux: старые активно использовали swap, современные более консервативны, что вызывает споры о настройках размера swap (от 1.5x RAM до полного отказа).

Safari в macOS 26 Tahoe затемняет видео при отображении нативных элементов управления, как это уже происходит в iOS 18. Это изменение, появившееся между iOS 16 и 18, теперь распространилось и на macOS, подтверждая тенденцию сближения двух операционных систем. Эффект исчезает, если убрать курсор или дождаться скрытия контролов.

Пользователи отмечают, что затемнение снижает видимость контента, что противоречит заявленным целям Apple по улучшению фокусировки. Изменение не связано со сторонними расширениями и воспроизводится даже при их отключении.

• Пользователи критикуют Apple за постепенное сближение macOS и iOS, выражая опасения по поводу утраты уникальности десктопной ОС.
• Многие участники обсуждают переход на Linux из-за растущего контроля Apple над macOS и снижения качества пользовательского опыта.
• Обсуждается конкретное изменение в Safari (затемнение видео при показе элементов управления) как пример нежелательного заимствования из iOS.
• Высказывается мнение, что критика отдельных изменений как признака слияния ОС преувеличена и нелогична.
• Некоторые пользователи отмечают, что подобные споры возникают ежегодно, но давление сообщества помогает сохранять macOS стабильной.

Исследование показало, что инверсия управления в играх связана не с привычкой или личными предпочтениями, а с особенностями восприятия пространства. Люди, которые инвертируют ось Y (когда движение джойстика вниз поднимает камеру), часто мысленно представляют себя внутри игрового мира, как будто управляют головой персонажа. Это похоже на то, как мы наклоняем голову назад, чтобы посмотреть вверх.

Учёные выяснили, что такой стиль игры чаще встречается у тех, кто вырос с ранними трёхмерными играми или авиасимуляторами, где инверсия была стандартом. Интересно, что это не связано с доминирующей рукой или полом. Практический вывод: игровые разработчики могли бы предлагать более гибкие настройки управления, учитывая разные когнитивные модели взаимодействия с виртуальным пространством.

• Обсуждаются две основные ментальные модели управления камерой: движение наблюдателя (толкнуть стик вверх, чтобы посмотреть вверх) и движение объекта (толкнуть стик вниз, чтобы "схватить" и наклонить объект вниз).
• Предпочтение инвертированной оси Y часто связывают с ранним опытом игры в авиасимуляторы, где такая схема является стандартной и отражает реальное управление.
• Многие пользователи отмечают, что их предпочтения зависят от контекста: инвертированное управление для транспортных средств/самолетов и обычное — для первого лица или пешего персонажа.
• Подчеркивается, что настройка является делом привычки и мышечной памяти, а не когнитивных способностей, и мозг способен адаптироваться к любой схеме.
• Высказывается frustration по поводу отсутствия единого системного параметра для инвертирования осей, который бы работал во всех играх.

WeAct Display FS — это компактный USB-дисплей за $2 с диагональю 0,96 дюйма и разрешением 160×80 пикселей. Он подключается к компьютеру или одноплатнику через обратимый USB Type-A порт, что позволяет гибко ориентировать экран. Устройство отображает системную информацию, погоду или пользовательские изображения через специальное ПО.

Программное обеспечение включает WeAct Studio System Monitor, форк проекта Turing Smart Screen на Python, который теоретически работает на Windows, macOS, Linux и Raspberry Pi OS. Для удобства использования в комплекте идут прокладки, предотвращающие короткое замыкание при перевороте USB-разъёма.

• Выражен интерес к USB-дисплеям с e-Ink, открытым интерфейсом и энергонезависимостью изображения, но отмечена высокая цена и дефицит подходящих моделей.
• Подняты серьёзные опасения по безопасности из-за риска подмены устройства клавиатурой для ввода вредоносных команд.
• Обсуждаются альтернативы: перепрошивка существующих устройств (ESP32, LilyGo), использование старых ридеров или более крупных дисплеев (M5Paper, reTerminal).
• Отмечен феномен покупки гаджетов "для проектов", которые затем не реализуются и пылятся.
• Высказано удивление распространением миниатюрных экранов в неожиданных местах как символа "будущего".

Первые Mac 1984 года с одноядерным процессором Motorola 68000 выполняли только одно приложение за раз. Переломным моментом стал Switcher (1985), позволявший переключаться между программами, но не запускать их одновременно. В 1987 году MultiFinder представил кооперативную многозадачность, где приложения добровольно уступали процессорное время — однако плохо написанный код мог заблокировать систему.

С появлением A/UX (1988) и Multiprocessing Services (1996) macOS перешла к вытесняющей многозадачности, где планировщик ОС сам распределяет ресурсы. К 2000 году Power Mac G4 с двумя процессорами и Mac OS X принесли поддержку потоков (threads) — легковесных задач в рамках процесса. Сегодня приложение (process) имеет главный поток и может создавать дополнительные, разделяя память, но с отдельными стеками. Это позволяет эффективно использовать многоядерные процессоры современным Mac.

• Участники отмечают неточности в статье о первых многопроцессорных Mac и истории потоков.
• Обсуждается, что для изучения истории потоков более релевантны ОС, отличные от Apple, например, NT, VMS или Solaris.
• Упоминаются ранние реализации потоков (нитей) в таких системах, как UNIVAC EXEC 8 (1966 г.) и библиотека «зеленых потоков» из Apache.
• Подчеркивается, что концепция потоков (threading) не обязательно связана с симметричной многопроцессорностью (SMP).
• Отмечается, что заголовок статьи может вводить в заблуждение, вызвав ожидания обсуждения другой темы.

Philips представила первый в мире цифровой патологоанатомический сканер с нативной поддержкой форматов DICOM JPEG и JPEG XL. Это позволяет генерировать совместимые с медицинскими стандартами изображения сразу на устройстве, без необходимости дополнительной конвертации. Конфигурируемые настройки вывода упрощают интеграцию с системами хранения и передачи медицинских данных, обеспечивая гибкость в работе с разными клиническими средами.

Использование JPEG XL значительно сокращает размер файлов при сохранении высокого качества изображений, что ускоряет передачу и анализ данных. Это особенно важно для цифровой патологии, где объёмы данных огромны. Новый сканер улучшает эффективность диагностики и снижает нагрузку на инфраструктуру медицинских учреждений.

• Philips переходит на стандартный формат DICOM для обработки патологических изображений, отказавшись от проприетарного формата iSyntax.
• Участники обсуждают технические сложности работы с огромными изображениями (60 000 x 60 000 пикселей) и форматами вроде JPEG XL, TIFF и JPEG2000.
• В сообществе существуют разногласия вокруг поддержки JPEG XL в браузерах, включая конспирологические теории о противодействии со стороны Google.
• Отмечаются проблемы с сервисом и поддержкой оборудования Philips в некоторых регионах, например, в Сингапуре.
• Обсуждаются практические сложности ручного экспорта слайдов в TIFF, который отнимает много времени у лаборантов.