Hacker News Digest

Swift.org анонсировали выпуск Swift SDK для Android, открывая новые возможности для кроссплатформенной разработки. Этот релиз стал результатом многолетних усилий сообщества и работы Android workgroup, которая расширяет возможности Swift за пределы традиционных платформ. SDK доступен в виде nightly preview релизов и может быть получен вместе с установщиком Windows или скачан отдельно для Linux и macOS.

Уже опубликовано руководство по началу работы и примеры приложений, демонстрирующие end-to-end рабочие процессы. Проект swift-java обеспечивает взаимодействие между Java и Swift, автоматически генерируя безопасные и производительные привязки. Интересно, что более 25% пакетов в Swift Package Index уже поддерживают Android, что упрощает перенос существующих проектов на новую платформу. Команда также работает над документом видения для будущих разработок Swift на Android и отслеживает прогресс через проект board.

• Обсуждение в основном вращается вокруг трёх тем: «кроссплатформенный» Swift теперь позволяет писать Android-приложения на Swift, но не решает проблему UI-фреймворков, а также не затрагивает вопросы лицензирования и тулинга.
• Участники обсуждения отмечают, что даже если Swift теперь работает на Android, это не делает его «флаттером» — он не предоставляет нативный UI, и разработчики всё ещё должны решать, как реализовать UI, что делает его менее привлекательным, чем Flutter или React Native.
• Некоторые участники высказывают мнение, что вместо того, чтобы пытаться сделать Swift кроссплатформенным, было бы лучше, если бы Apple открыла Xcode и позволила бы использовать его на других платформах.
• Обсуждение также затрагивает вопрос о том, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.
• Участники также обсуждают, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.

Технология тепловых насосов существует уже более века и является высокоэффективной — в 2-4 раза эффективнее традиционных печей. Современные модели могут заменить одновременно печь и кондиционер, работая практически во всех климатических зонах, и по стоимости эксплуатации часто сопоставимы с самым дешевым вариантом отопления — природным газом. Несмотря на наличие технологий и политической поддержки, массового внедрения в США не происходит.

Автор статьи, предприниматель Джозеф ДеНатале, утверждает, что главная проблема не в технологиях, а в людях: домовладельцах, подрядчиках, производителях и политиках. Он подчеркивает, что "самая сложная часть — не идея, а ее реализация". Статья будет опубликована в пяти частях в течение нескольких недель и исследует, что необходимо сделать, чтобы тепловые насосы стали очевидным, доступным и стандартным выбором для миллионов американских домов.

• Установка теплового насоса в США стоит $20-30 тыс., что в 3-4 раза дороже, чем в Европе или Японии, и это не оборудование, а именно установка.
• В США нет культуры "сделай сам", и это не только из-за сложности установки, но и потому, что нет доступных в продаже систем.
• В США нет культуры "сделай сам", и это не только из-за сложности установки, но и потому, что нет доступных в продаже систем.
• В США нет культуры "сделай сам", и это не только из-за сложности установки, но и потому, что нет доступных в продаже систем.

В предоставленном тексте содержится только начало статьи "Почему я пишу код, будучи CTO" от Джона Ванга, соучредителя и технического директора компании Assembled. Статья начинается с констатации того, что многие технические директора перестали писать код несколько лет назад. Однако полного содержания статьи для создания полноценного пересказа недостаточно. Для подготовки точного и ёмкого пересказа необходимо предоставить полный текст статьи.

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

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

Ключевое различие - разный уровень автономии для основных и второстепенных задач. Для творческой работы требуется быстрый отклик и контроль, тогда как для рутины важен конечный результат. Этот подход решает проблему иерархии статусов в командах - ИИ может выполнять "грязную работу" без создания низкостатусных ролей. Идея "главного программиста" с поддержкой команды, описанная Фредом Бруксом в 1975 году, теперь экономически реализуема благодаря ИИ, что позволяет сосредоточиться на главном, делегируя второстепенное.

• Обсуждение вращается вокруг аналогии "как хирург" и того, как она применяется к использованию ИИ-инструментов в разработке ПО: от идеи, что "хирург" — это не менеджер, а тот, кто делает реальную работу, а команда поддержки — это аналог анестезиолога и медсестер, до споров о том, кто и в какой момент считается "хирургом", и до обсуждения того, что такой подход может влиять на обучение и рост младших разработчиков.
• Участники обмениваются мнениями о том, как соотносятся такие концепции с такими же идеями Фреда Брукса о "хирургической команде", и о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков.
• Некоторые участники поднимают вопросы о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.
• Участники также обсуждают, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.
• В обсуждении также поднимается вопрос о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.

Недавно на рейсе British Airways из Гонконга в Лондон автор обнаружил бесплатный WiFi для "сообщений" через программу лояльности. Оказалось, что для регистрации достаточно ввести email без верификации прямо в полёте. Бесплатный интернет работал с WhatsApp, Signal и WeChat (без изображений), но блокировал Discord и обычные сайты.

Автор выяснил, что система использует SNI (Server Name Indication) из TLS-рукопожатия для определения типа трафика. SNI раскрывает домен до установления шифрования, позволяя авиакомпании блокировать не-whitelisted домены. Эксперименты показали, что даже прямые подключения по IP без SNI блокируются, а использование SNI от WhatsApp (wa.me) обходит ограничение, позволяя установить соединение с любым сайтом через хост-заголовок HTTP.

• Обсуждение началось с описания способа обхода ограничений Wi-Fi в самолётах и круизных лайнерах с помощью VPN, DNS-туннелирования и прочих техник, включая использование порта 53/UDP и DNS-over-HTTPS.
• Участники обменялись историями о том, как они обходили плату за Wi-Fi в полёте, используя различные комбинации инструментов вроде OpenVPN, WireGuard, Iodine и прочих.
• Обсуждались также такие темы, как SNI-утечки, обфускация трафика и их влияние на приватность пользователей.
• Упоминались также вопросы о том, как авиакомпании и другие транспортные компании могут отслеживать и ограничивать использование VPN и прокси-серверов.
• В конце обсуждение перешло к обсуждению более широких тем, таких как приватность и безопасность в сети, а также о том, как технические меры могут быть использованы для обхода цензуры и ограничений.

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

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

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

Команда Asahi Linux продолжает работу над поддержкой чипов Apple M3, хотя на данный момент базовая функциональность позволяет только загружать систему до мигающего курсора. Разработчики активно портируют загрузчик m1n1 на язык Rust, что повысит безопасность и поддерживаемость критически важного компонента. Параллельно ведется работа над патчами ядра Linux для версий 6.17 и 6.18, где уже добавлены Device Trees для устройств Apple M2 Pro/Max/Ultra.

Успехи также отмечены в игровой сфере — Wine теперь работает вне muvm, а поддержка графики продолжает совершенствоваться. Несмотря на прогресс с M1 и M2, чипы M3, M4 и недавно анонсированный M5 все еще находятся в стадии обратной разработки. Как отмечают разработчики: "Базовая поддержка M3 существует давно, но она ограничивается возможностью загрузки до мигающего курсора, что полезно только для низкоуровневого реверс-инжиниринга".

• Пользователи обсуждают, что владельцы Mac на M1-M4 чипах по-прежнему не могут полноценно использовать Linux на своих машинах, и это вызывает тревогу, особенно учитывая, что Apple не проявляет особого интереса к поддержке Linux на своих устройствах.
• Участники обсуждения отмечают, что даже несмотря на это, сама по себе поддержка Asahi Linux остается важной, так как она позволяет продлить жизнь этих устройств, когда Apple прекратит поддержку macOS.
• Некоторые участники подчеркивают, что ситуация с Linux на Apple Silicon выглядит как бесконечная борьба, и что это может быть неразрешимой проблемой, если Apple не изменит свою политику.
• Также обсуждается, что в то время как Apple продолжает выпускать новые чипы, Asahi Linux может не успевать за ними, что делает невозможным поддерживать актуальные версии ядра и драйверов.
• Наконец, участники обсуждения отмечают, что существует альтернатива в виде ноутбуков от других производителей, которые лучше подходят для Linux, но они не такие же качественные, как MacBook, что делает выбор сложным для тех, кто предпочитает Linux, но привык к премиальному качеству MacBook.

Вышел Typst 0.14 с фокусом на доступность - теперь документы генерируются с поддержкой доступности по умолчанию, что соответствует международным стандартам PDF/UA-1. Это позволяет соответствовать таким регуляциям, как Европейский закон о доступности (EAA) и ADA Title II. Помимо доступности, в обновлении добавлена поддержка PDF как нативного формата изображений для сложных иллюстраций, улучшено выравнивание на уровне символов для книг и значительно расширен функционал экспорта в HTML.

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

• Typst и LaTeX соревнуются в академической среде: Typst — быстрая компиляция, меньше боли при работе с шаблонами, но пока не поддерживает такие вещи как beamer и TikZ.
• Пользователи отмечают, что Typst легко учится и использует современный синтаксис, но отсутствие поддержки для сложных научных документов и журналов остаётся барьером для широкого внедрения.
• Поддержка PDF/UA и встроенная обработка PDF делают Typst привлекательным для тех, кто заботится о доступности, но отсутствие индексации и библиографии может быть препятствием для академических пользователей.
• Несмотря на то, что Typst — это open-source проект с открытым исходным кодом, он использует проприетарный онлайн-редактор и «Typst Universe» — что вызывает вопросы о свободе и будущем.
• Сообщество продолжает расти, и в то же время Typst быстро развивается, добавляя новые функции и улучшая существующие. Это показывает, что Typst — это не просто еще один инструмент, а живой проект, который может в конце концов стать стандартом для публикации научных работ.

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

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

• Обсуждение показало, что технические характеристики (синхронизация, безопасность, производительность) важны, но устойчивость проекта и наличие сообщества в долгосрочной перспективе могут быть ещё более критичными факторами.
• Участники подчеркнули, что даже при наличии open-source решений, отсутствие ясной модели финансирования и поддержки может привести к прекращению проекта.
• Сравнение с Nextcloud и Seafile показало, что пользователи ищут баланс между простотой установки и гибкостью, но при этом критично важно, чтобы проект не исчез через год-два.
• Несколько комментаторов отметили, что важно не только иметь открытый исходный код, но и обеспечить прозрачность в модели угроз и процессе принятия решений.
• Вопрос о том, как проект планирует привлечь и удерживать вкладчиков, остался без ответа, что может быть самым слабым местом.

Технический комитет Debian отменил изменение в systemd, сделавшее каталог /run/lock доступным только для записи root-пользователя, что нарушило работу нескольких программ. Debian packagers имеют свободу настройки пакетов, но должны соответствовать Debian Policy, которая ссылается на устаревший стандарт FHS, предписывающий использование /var/lock (символическая ссылка на /run/lock). Изменение в systemd v258 сломало утилиты вроде UUCP и cu, а разработчик alsa-utils предупредил, что удаление каталога создаст "ловушку для дистрибутивов", заставляя их создавать локальные обходные пути без видимой пользы.

Debian 13 (trixie) использует systemd v257 и не затронуты проблемой, но изменения в unstable ветке вызвали сбои. Хотя FHS не поддерживается с 2010 года, Debian Policy продолжает его цитировать. systemd планирует полностью удалить /run/lock в v259, предлагая пользователям создавать конфигурационные файлы для сохранения старого поведения. Разработчик предложил компромисс, сделав каталог доступным для группы dialout вместо всемирной записи, но техкомитет Debian настоял на соответствии политике проекта.

• Debian Policy всё ещё ссылается на FHS, хотя тот не обновлялся более десятилетия, и это вызывает споры о том, какой уровень «поддержки» требует стандарт.
• Разработчики systemd считают, что /run/lock должен быть доступен для записи всем, что вызывает конфликт с безопасностью и совместимостью с другими пакетами.
• Поддержка FHS в Debian в основном сводится к тому, что «мы не хотим ломать совместимость с 3-летней давностью», даже если это означает отказ от безопасности.
• Архитектура /usr merge и другие изменения, которые уже стали нормой в других дистрибутивах, в Debian обсуждаются в контексте FHS, что вызывает вопросы о том, как долго ещё будет существовать текущий подход.
• В конце концов, вопрос остаётся открытым: будут ли разработчики Debian и systemd находить общий язык, или же приведёт ли это к форку или отказу от одного из них.