Hacker News Digest

Исследователи Project Zero обнаружили уязвимость в защите KASLR на устройствах Android с процессорами arm64. Оказалось, что из-за поддержки горячего подключения памяти (memory hotplug) линейное отображение ядра больше не рандомизируется, а PHYS_OFFSET всегда имеет фиксированное значение 0x80000000. На Pixel-телефонах загрузчик дополнительно распаковывает ядро по одному и тому же физическому адресу (0x80010000) при каждой загрузке, что делает возможным статическое вычисление виртуальных адресов для любых данных ядра.

Эта уязвимость позволяет злоумышленникам с примитивом для произвольной записи обходить KASLR без сложных техник утечки адресов. Исследователь Seth Jenkins продемонстрировал, как с помощью формулы phys_tovirt(x) = ((x) - 0x80000000) | 0xffffff8000000000 можно точно вычислять виртуальные адреса для ядерных структур, таких как modprobe_path. Команда разработала инструмент bpf_arb_read для чтения экспортируемых переменных ядра, что упрощает эксплуатацию этой уязвимости.

• Hendrikto сообщил о двух проблемах: отсутствии рандомизации линейного отображения и статичном физическом адресе загрузки ядра в Pixel, но обе считаются ожидаемым поведением.
• Google Pixel может добавить рандомизацию физических адресов ядра позже, но конкретных планов по устранению проблем нет.
• i-con указывает на параллель с уязвимостью в KVM (проект Rain) и сомневается в необходимости постоянного отображения всей физической памяти.

В функциональном программировании высшие функции вроде map, filter и fold можно определить через reduce, показывая что "всё сворачивается". Эти функции зависят от коллекций лишь через операцию conj, что открывает путь к абстракции. В Clojure это реализуется через трансдьюсеры — функции, принимающие шаг обработки и возвращающие его модифицированную версию.

Трансдьюсеры позволяют создавать переиспользуемые преобразования данных, работающие с различными структурами, от списков до потоков. Их ключевое преимущество — композиция: несколько трансдьюсеров могут объединяться без потери производительности. Реализация поддерживает разные арности (0, 1 или 2 аргумента), что делает их универсальными для различных сценариев обработки данных. Такой подход обеспечивает как переиспользование кода, так и высокую производительность за счет meaningful абстракции.

• Обсуждение началось с предложения рассмотреть альтернативное, более мягкое введение в трансдюсеры как функции a -> List<b>, подчеркивая их полиморфизм и простоту.
• Участники поделились опытом, что новички в Clojure часто переоценивают reduce и пытаются заменить им циклы, что приводит к запутанному коду, в то время как трансдюсеры предлагают более чистый и декларативный подход.
• Сообщество единодушно подтвердило, что трансдюсеры действительно делают код более выразительным и устойчивым к ошибкам, особенно когда дело касается обработки коллекций.
• В итоге обсуждение сошлось на том, что хотя трансдюсеры и требуют некоторого переосмысления привычных паттернов, их преимущества в выразительности и надежности делают их ценным инструментом для Clojure разработчика.

В середине XIX века Бернхард Риман представил новый способ мышления о математических пространствах, заложив основу современной геометрии и физики. Многообразия — это формы, которые выглядят плоско для существ, живущих на них, хотя могут иметь сложную глобальную структуру, подобно тому как человек на поле может забыть, что Земля круглая. Это понятие изменило представление о пространстве, превратив его из физической среды в абстрактный объект, достойный изучения сам по себе.

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

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

К сожалению, я не вижу содержимого статьи, на которую вы ссылаетесь. Ваш запрос содержит только заголовок "7 sets Venn Diagram" и сообщение о несовместимости браузера с Canvas.

Для создания точного пересказа мне нужен текст статьи или ее основные тезисы. Если у вас есть доступ к содержимому, пожалуйста, предоставьте его, и я с удовольствием подготовлю краткое изложение в соответствии с вашими требованиями.

• Для визуализации более 3 множеств рекомендуется использовать UpSet-диаграммы вместо сложных диаграмм Венна.
• Диаграммы Венна с 5 и более множествами считаются практически бесполезными и плохо читаемыми.
• Существует математическая теория (например, диаграммы Эдвардса-Венна) для построения диаграмм Венна для произвольного числа множеств.
• Визуализация диаграмм Венна ограничена 3 множествами в 2D и 4 множествами в 3D при использовании круглых форм.
• На некоторых платформах (iOS Safari, Android Firefox/Chrome) отображение интерактивных диаграмм работает некорректно.

• Обсуждение охватывает широкий спектр тем: от исторических примечаний к фильтрам Блума до их практического применения в индустрии и академических исследованиях.
• Участники обсуждали различные аспекты фильтров Блума, включая их эффективность, ограничения и альтернативы, такие как Cuckoo и Ribbon фильтры.
• Были упомянуты конкретные примеры использования фильтров Блума в таких системах, как Splunk и Bing.
• Обсуждались также вопросы, связанные с оптимизацией производительности и использованием фильтров Блума в различных контекстах, включая поиск редких событий и обработка больших объемов данных.

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

Реальные Java-файлы часто содержат такие "неестественные" конструкции, что делает проблему важной для любого декомпилятора. Автор также отмечает сложность обработки try...finally блоков, где код finally должен выполняться независимо от возникновения исключения, но передача управления после его завершения зависит от контекста. Эти особенности байткода и компилятора javac создают значительные препятствия для создания корректного декомпилятора, особенно при попытке восстановления исходной структуры кода.

• Обсуждение началось с примера кода, который выглядит как баг, но на самом деле является корректным поведением в Java и других языках, где finally блок не может перехватить return/throw, но может перехватить continue/break.
• Участники обсудили, что в действительности это не баг, а фича, и что в большинстве языков finally не может перехватить return/throw, но может перехватить continue/break.
• Обсуждались также вопросы, что в некоторых языках, таких как C#, такие конструкции вообще не допускаются.
• Также было отмечено, что в Java 25 такой код будет компилироваться и работать, но в более ранних версиях Java это вызовет ошибку компиляции.

За десять лет автор прошёл путь от веб-разработчика до специалиста по базам данных, присоединившись к EnterpriseDB, где работает над pglogical и Postgres Distributed. Его карьера началась в 2014 году с JavaScript и Python, затем он стал менеджером инженеров. Прорывным моментом стало 2020 год, когда проблемы с производительностью его сервиса заставили его изучить индексы и структуры данных. Он создал образовательные проекты, включая простую in-memory SQL базу данных, и построил сообщества вроде Software Internals Discord и /r/databasedevelopment.

После неудачной попытки запустить собственный стартап в 2021-2023 годах и работы в TigerBeetle автор искал позицию именно разработчика баз данных, а не DevOps-инженера для работы с базами. Несмотря на нетрадиционный путь (он бросил колледж) и сомнения работодателей, он получил три предложения на работу над расширениями Postgres на C и Rust. Выбрав EnterpriseDB, компанию с 20-летней историей и одним из крупнейших вкладчиков в развитие Postgres, он предпочёл стабильность ранним стартапам, в которых работал последние три года.

• Сообщество обсуждает, как трудно сменить специализацию, если ты уже «записан» в базе данных как специалист в области X, и как это влияет на найм и карьерные возможности.
• Участники делятся личным опытом: кто-то ушел в разработку на C/C++ и Rust, кто-то перешел в SRE или DevOps, кто-то пытается попасть в компиляторы.
• Обсуждается, что рекрутеры и системы найма не видят за пределами ключевых слов в резюме и не учитывают site-reliability, DevOps и прочие смежные навыки, что делает смену специализации еще более сложной.
• Участники делятся советами, как обойти эту систему: делать сайд-проекты, которые демонстрируют навыки в новой области, участвовать в open-source, писать блоги и статьи, и так далее.
• Также обсуждается, что важно не только выждать подходящий момент, но и быть готовым пойти на уменьшение зарплаты и не бояться начать с более низкой позиции, что может быть ключом к переходу в новую область.

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

• Пользователи критикуют официальный клиент Microsoft Teams за многочисленные баги, проблемы с производительностью и отсутствие функций (например, PiP и видео-меню).
• Неофициальный клиент для Linux предлагается как альтернатива с меньшим количеством ошибок, дополнительными возможностями (например, PiP) и лучшей интеграцией с системой (уведомления в трее).
• Некоторые предпочитают использовать Teams через веб-версию или PWA, но отмечают ограничения (например, проблемы с обменом экраном в Firefox, задержки уведомлений).
• Проект неофициального клиента вызывает споры: некоторые сомневаются в его поддержке из-за возможного использования AI для генерации кода, другие отмечают его полезность для Linux-пользователей.
• Несмотря на критику, Teams остаётся необходимым инструментом в профессиональной среде, особенно в компаниях, использующих экосистему Microsoft.

Исследование MMC о состоянии агентного ИИ показывает, что 62% стартапов уже привлекают бюджеты бизнес-направлений, доказывая переход технологии из экспериментальной фазы. Основные проблемы внедрения не технические: интеграция рабочих процессов (60%), сопротивление сотрудников (50%) и вопросы безопасности данных (50%). Успешные стратегии следуют принципу "Think Small", начиная с низкорисковых задач с быстрой окупаемостью, особенно когда ИИ автоматизирует неприятные для людей задачи.

Точность решений превышает 70% у 90% компаний, при этом 52% стартапов строят инфраструктуру внутри компании. Наиболее популярные модели ценообразования - гибридная и за задачу (по 23%), в то время как модель на основе результатов используется лишь 3% из-за сложности измерения. Как отмечают Марк Беннайофф и Сатья Наделла, восприятие Copilot колеблется между "Clippy 2.0" и "Clippy после десятилетия в спортзале", что подчеркивает важность правильного позиционирования.

• Основные барьеры внедрения агентных AI — не технические (производительность моделей), а организационные: интеграция в рабочие процессы, недоверие сотрудников и вопросы приватности данных.
• Системы склонны к накоплению ошибок, что требует постоянного контроля человека ("human in the loop"), особенно в критичных приложениях (финансы, здравоохранение).
• Наблюдается скепсис по поводу реальной пользы многих AI-решений: инвестиции часто не оправданы, а системы могут генерировать недостоверные данные.
• Агентные AI сложно методически оценивать, а их непредсказуемость в открытых контекстах требует тщательного инженeringа для снижения рисков.
• Выводы о проблемах внедрения могут быстро устаревать из-за быстрого развития технологий.

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

• Обсуждение вращается вокруг поиска «идеального» языка для GPU-программирования, но при этом не предлагается конкретный язык, а вместо этого обсуждаются причины, по которым такой язык ещё не существует.
• Участники упоминают Futhark как единственный существующий пример языка, который хоть как-то приближается к идеалу, но при этом подчеркивается, что даже Futhark не предоставляет нужные абстракции и что его синтаксис не оптимален.
• Обсуждается, что вместо поиска универсального языка, фокус на специфичных библиотеках вроде cuDF, RAPIDS и т.д. может быть более продуктивен, но при этом такие библиотеки не решают проблему в целом.
• Участники также обсуждают, что вместо попыток создать новый язык, мог бы быть лучше улучшить существующие языки, но при этом такие улучшения не решают фундаментальные проблемы отсутствия нужных абстракций в этих языках.
• В конце концов, обсуждение сводится к тому, что идеальный язык должен предоставлять способ выразить вычисления как последовательность операций над масивами, что является фундаментальным способом выражения вычислений в параллельных системах, но никакой из существующих языков это не делает.