Hacker News Digest

• Слепые активно внедряют ИИ: Be My Eyes описывает картинки через ChatGPT, подкастеры хвалят LLM, а дикторы отдают голоса ElevenLabs.
• Я скептик: LLM даёт ошибки, но это всё же данные, которые зрячие нам не предоставляют.
• Парадокс: я не стану нанимать диктора, использующего синтез речи, но это может выглядеть как дискриминация.
• Когда хайп уляжется, слепые будут требовать доступности самих платформ и их вывода; веб-станет менее доступным, потому что ИИ пишет плохой код.
• Повторяется история OCR и беспилотников: обещаний много, прогресса мало.
• Сейчас LLM применяют, чтобы описывать персонажей, клипы и т. д.; точность не важна, важно хоть что-то получить.
• Сообщество верит, что технологии решат всё, потому что люди не хотят помогать.

• Слепые и слабовидящие активно используют LLM и мультимодальные ИИ для описания изображений, OCR и повседневных задач, считая технологию «меньшим злом», чем полное отсутствие помощи со стороны людей.
• Одновременно они предупреждают: чрезмерная вера в ИИ может стать оправданием для производителей не делать изначально доступные интерфейсы и снижать инвестиции в «настоящую» доступность.
• Участники отмечают, что ИИ-ответы часто содержат ошибки и галлюцинации, но даже 85 % правильной информации лучше, чем ничего; критично важно уметь оценивать доверие к результатам.
• Примеры вроде Be My Eyes показывают, что живое человеческое участие всё ещё востребовано, хотя объём звонков может падать после появления ИИ-функций.
• В дискуссии звучит тревога по поводу замены людей (дикторов, переводчиков) дешёвыми ИИ-«заглушками», что снижает качество контента.
• ИТ-стандарты (IETF) уже обсуждают, нужно ли явно разрешать обход «AI-предпочтений» ради вспомогательных технологий, сталкиваясь с сопротивлением правообладателей.

CVE-2024-50264: кратко о сложнейшей гонке в AF_VSOCK
Уязвимость введена в 2016 г. (ядро 4.8); это race между connect() AF_VSOCK и POSIX-сигналом, приводящий к UAF 80-байтового объекта virtio_vsock_sock. Триггер доступен обычному пользователю без user-ns. Ограничения: объект быстро освобождается, UAF-запись делает kworker, система легко падает. За это баг получил Pwnie 2025 «Best Privilege Escalation».

Управление сигналом без самоубийства процесса
Вместо SIGKILL, который убивает эксплойт, используется «бессмертный» сигнал 33:

sev.sigev_signo = 33;
timer_create(CLOCK_MONOTONIC, &sev, &race_timer);
timer_settime(...);  // точный момент прерывания connect()

Сигнал 33 зарезервирован NPTL, процесс его не видит и не завершается.

kernel-hack-drill: тренажёр для ядерных атак
Проект https://github.com/a13xp0p0v/kernel-hack-drill автоматизирует:

• сборку нужных версий ядра Ubuntu 24.04 (6.11 OEM/HWE) с разными конфигурациями KASLR/KCFI/SLAB_QUARANTINE;
• запуск в KVM с заданным RAM/CPU и ssh-форвардингом;
• однокнопочный запуск PoC и сбор crash-дампов.

Инструмент позволил быстро перебирать стратегии перераспределения kmalloc-96, искать объекты-спрей, тестировать разные техники обхода защит и отлаживать эксплойт без ручной пересборки ядра.

Новый путь эксплуатации
Автор отказался от сложной цепочки @v4bel и @qwerty и применил упрощённую схему:

1. Спрей sendmsg()-controlled объектами размером 96 байт, чтобы перехватить освобождённый virtio_vsock_sock.
2. UAF-запись переписывает поле sk_prot, указывая на поддельную структуру proto в userspace-буфере.
3. При последующем вызове close() ядро переходит по контролируемому указателю и исполняет ROP-цепочку, поднимая shell до root.

kernel-hack-drill сократил время от идеи до рабочего PoC с недель до нескольких часов.

• Участники в восторге от глубокого и единоличного описания use-after-free, но признают, что текст местами труден для чтения из-за «роботизированной» подачи.
• Многие чувствуют себя «бесполезными» на таком низком уровне и восхищаются талантом исследователей уязвимостей.
• Поднимается вопрос о мотивации: исследователи редко чинят баги, потому что это требует других навыков и ломает их инсентивы.
• Обсуждается, поможет ли Rust в ядре Linux: write-after-free технически блокируется, но unsafe-области всё ещё оставляют риски.

• Lit — простая, быстрая библиотека для Web Components
• Bluesky: lit.dev

---

Основные плюсы

• Simple
  Минимум шаблонного кода: реактивность, декларативные шаблоны, продуманные фичи.

• Fast
  ≈ 5 КБ (сжато), рендер только изменённых частей, без виртуального DOM.

• Web Components
  Нативные кастом-элементы работают в любом фреймворке и без него.

---

Мини-пример

import {html, css, LitElement} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
  static styles = css`p { color: blue }`;
  @property() name = 'Somebody';
  render() {
    return html`<p>Hello, ${this.name}!</p>`;
  }
}

<simple-greeting name="World"></simple-greeting>

Попробовать в Playground

---

Возможности

• Custom Elements — встраиваются как обычные теги.
• Scoped styles — Shadow DOM изолирует CSS.
• Reactive properties — автоматический перерендер при изменении.
• Declarative templates — нативные литералы, без компиляции.

---

Что строят на Lit

• Shareable Components — капсулы для любого стека.
• Design Systems — единые компоненты под разные фреймворки.
• Sites & Apps — постепенное улучшение или полные приложения.

---

Кто использует

Adobe Spectrum, Alaska Auro, Cisco Momentum, Home Assistant, IBM Carbon, Lion, Pharos, PWA Starter, SAP UI5, Shoelace, Hilla, Clarity, Wired Elements и др.

---

Учимся и общаемся

• Туториалы
• Playground
• Документация
• Get started

• Кто-то рад избавиться от Lit, считая его лишним слоем; другие называют «недооценённой» и «лучшей абстракцией» над Web Components.
• Пользователи хвалят маленький размер, отсутствие бойлерплейта и лёгкость внедрения в legacy-проекты, но жалуются на shadow DOM (проблемы a11y, стили) и отсутствие SSR.
• Некоторые вообще отказались от фреймворков и пишут «сырые» web-компоненты, считая, что Lit лишний.
• Вопросы к мейнтейнеру: SSR, реактивность свойств, взаимодействие со сторонними компонентами, работа без бандлера.

• В финском городе Пори запущена песчаная батарея мощностью 1 МВт и ёмкостью 100 МВт·ч; она нагревает 100 тонн обычного строительного песка до 600 °C.
• Устройство преобразует избыточную электроэнергию в тепло и хранит её до 100 часов, отдавая по мере спроса для отопления зданий.
• Проект разработала компания Polar Night Energy; капитальные затраты составили около 10 млн €, что дешевле литий-ионных систем аналогичной ёмкости.
• Песчаная батарея не содержит редких металлов, служит десятилетиями и легко масштабируется, что делает её привлекательной для северных регионов с длинными холодными сезонами.

• Пользователи обсуждают «песочную» тепловую батарею в Финляндии: технология интересна, но вызывает вопросы о рентабельности.
• Ключевые плюсы: дешёвые материалы (песок), высокая температура (до 500 °C), 90 % тепловая отдача, простота конструкции.
• Основные минусы: отсутствие публичных расчётов ROI, потеря эффективности при преобразовании тепла в электричество, невозможность использовать тепловой насос при 500 °C.
• Сравнение с водой: вода дешевле и лучше проводит тепло, но ограничена 100 °C и требует герметичных ёмкостей.
• Для работы нужна сеть централизованного отопления; в Финляндии она уже есть, что упрощает внедрение.

• rbanffy выложил 3D-модель шарика IBM Selectric со шрифтом Comic Sans и хочет достать саму пишущую машинку.
• Участники обсуждают, что модель ещё не тестировали, но авторы предыдущих версий уже печатали и даже сняли видео.
• Некоторые в восторге от идеи кастомных шариков (включая IBM Plex Mono и Papyrus), другие шутят о Comic Sans как «враге публичной типографики».
• Общий тон: увлечённость ретро-техникой, культура «ремикса» в 3D-печати и ностальгия по Selectric.

ZSF нужны деньги!
Сбор средств 2025: 28 дней осталось, талисманы пока на нуле.
Пожертвовать

---

Расходы 2024 (итого $520 749)

• Контракторы – $306 362 (92 % бюджета, $60/час).
• Сотрудники – $154 263 (один Andrew Kelley).
• Бухгалтерия – $18 464 (Strada Financial Group).
• CI и сайт – $14 987 (железо + Hetzner).
• Налоги – $13 089.
• Поездки – $6 956 (Италия, Германия).
• Спонсорство – $5 846 (musl, mingw-w64 и др.).
• Банковские комиссии – $782.

---

Что сделано в 2024

• Выпущены Zig 0.13.0 и 0.14.0 (расширены цели, язык, стандартная библиотека, билд-система).
• 0.14.1 – только фиксы.

---

Доходы и тренд

• Пожертвования постепенно снижаются.
• Пик – половина $300 000 от Mitchell Hashimoto.
• Вторую половину нужно заменить, чтобы не уйти в минус.

---

Рост нагрузки

• Активность пользователей и количество GitHub-issues растут быстрее, чем закрываются.

• Участники хвалят Zig Foundation за прозрачность отчёта и модель оплаты контрибьюторов, но удивлены отсутствием крупных корпоративных спонсоров.
• Основатель получает $150 тыс. после налогов из пожертвований; многие считают это оправданным, но рекордным для GitHub Sponsors.
• Вопросы вызвали статья расходов на налоги с зарплат и $15 тыс. на CI/сайт: одни видят расточительство, другие — норму для такой инфраструктуры.
• Представитель Zig подтвердил открытость к корпоративным спонсорам без уступки мест в совете.

Как ускорить запуск Unreal Editor: не создавать 38 000 тултипов

Unreal Editor запускается долго. Epic борется с этим кэшами, live-coding и прочими оптимизациями, но одна простая проблема оставалась незамеченной: на старте движок генерирует 38 000 виджетов-тултипов, хотя за сессию пользователь видит лишь десяток.

Профилирование показало, что SetToolTipText тратит ~0,2 мс на каждый тултип, но главное — он не просто сохраняет текст, а сразу создаёт полноценный виджет. В итоге:

• 2–5 с потеряно в дебаг-сборке
• до 1 с в development
• ~40 МБ ОЗУ занято невидимыми виджетами

Решение

1. Заменить немедленное создание виджета на ленивое: сохранять только FText.
2. Создавать виджет в момент первого обращения (GetToolTip).

Патч — пара строк: убрать Spawn из сеттера, перенести его в геттер.
Результат: стартовое время падает на ~1 с, ОЗУ экономит десятки мегабайт, а в рантайме задержки не заметны — тултипы всё равно редко вызываются пачками.

• UE создаёт 38 000 тултипов при старте редактора, что занимает до 2–5 с в дебаг-сборке и почти 1 с в дев-сборке.
• Каждый «тултип» — полноценный UI-виджет с саб-объектами, а не просто строка текста.
• Проблема решается ленивым или единичным созданием экземпляров, как в IMGUI/Unity/React-порталах.
• Участники жалуются на медленную итерацию UE: 10 мин компиляция пустого проекта, бесполезный блюпринт-бол, жадность до железа.
• Альтернативы: Godot (GDScript, быстрая итерация), Unigine, форк Hazelight с AngelScript.

%CPU — обманка
Система показывает 50 % загрузки, но реально сервер выполняет 60–100 % максимально возможной работы.

Эксперимент
Ryzen 9 5900X (12 ядер / 24 потока), Turbo включён.
Скрипт запускал stress-ng двумя способами:

• 24 потока по 1–100 % нагрузки;
• 1–24 потока по 100 %.

Результаты

• Общий CPU-тест: при 50 % «утилитой» реальная работа 60–65 %.
• 64-битная математика: 65–85 %.
• Умножение матриц: 80–100 %.

Почему так

1. Hyper-threading: после 12 потоков «ядра» делят ресурсы, прирост стремится к нулю.
2. Turbo: частота падает с 4.9 до 4.3 ГГц при росте загрузки, поэтому «утил» растёт быстрее реальной работы.

Вывод
Полагаться на линейный рост %CPU — ошибка. При эффективной загрузке (>50 %) показания занижены, и различия между процессорами могут быть огромными.

• Участники сходятся во мнении, что «%CPU» — это не ложь, а линейная мера нелинейной реальности: SMT, Turbo, общие ресурсы и ожидание памяти делают 60 % «загрузки» фактически пределом.
• Практики SRE подтверждают: модели очередей по CPU% работают лучше «старой мудрости», но только если понимать, что 50–60 % уже «почти всё».
• Несколько человек вспомнили, как менеджеры требовали «увеличить сервер», увидев 100 %, хотя процессор простаивал в busy-wait или ждал I/O.
• Подчёркивается, что IPC, latency, power-draw и прямое нагрузочное тестирование приложения дают более точную картину, чем сырые проценты.
• Утилита stress-ng удобна для синтетики, но не для production-бенчмарков; реальные приложения (Postgres, Memcached) ломаются раньше, чем показывает 100 % CPU.

• Векторы и матрицы: LLM всё превращают в вектора; главное — скалярное произведение и умножение матриц.
• Softmax: превращает логиты в вероятности; температура регулирует «уверенность».
• Градиент и производная: показывают, как чуть изменить вес, чтобы ошибка уменьшилась.
• Цепное правило: позволяет распространить ошибку через слои; сердце backprop.
• Эмбеддинги: строки → векторы; чем ближе векторы, тем похожее значение.
• Attention: Q·K^T выделяет релевантные токены; V несёт смысл; маска прячет будущее.
• MLP в трансформере: два линейных слоя с ReLU; увеличивает выразительность.
• LayerNorm: стабилизирует распределение после каждого подслоя.
• Позиционное кодирование: добавляет «адрес» токену, иначе порядок теряется.
• Лосс (cross-entropy): средняя «удивлённость»; оптимизатор (Adam) крутит веса.

Дальше — только масштаб: больше слоёв, голов, данных и видеокарт.

• Физики и математики вспомнили, что знание тензорного исчисления, линалгебры и энтропии пригодилось для понимания backprop и LLM.
• Практика: «смотреть» Karpathy недостаточно — нужно кодить за ним; его курс даёт базы и уверенность копать дальше.
• Книга «Build a Large Language Model (from Scratch)» идёт шаг-за-шагом, но объясняет только вычисления, а не «почему это вообще работает»; explainability всё ещё исследуется.
• Путаница: эмбеддинги ≠ вся модель; они лишь вход для трансформера, внутри которого 1,8 трлн параметров и «чёрный ящик».
• LLM — логит-генераторы с неизбежной неопределённостью; цепочки моделей накапливают ошибку и быстро «ломаются» без человека-оркестратора.
• Для 99 % разработчиков хватает линалгебры, softmax, градиентов и PyTorch; остальное — инженерия данных, трюки и эксперименты.

Блог работает на переработанном Google Pixel 5

Вдохновившись постами в Mastodon о сайтах на ESP32 и Android-солнечных панелях, решил запустить блог с телефона. Успешно: вы это читаете.

Железо

• Google Pixel 5, от Verizon, без разблокировки загрузчика.
• Поддержка USB-OTG и Ethernet-адаптера.
• Питание: 100 Вт солнечная панель + Jackery 160 Вт — сайт полностью автономен.

Софт
Termux + Hugo из репозитория. Пакеты: git, screen, openssh, hugo, dufs (веб-загрузка файлов).
Сервисы: sshd, cronie через sv-enable.

Опыт
Первые сутки — разные версии Hugo и контроль заряда. Сейчас всё стабильно и быстро; внешне не отличить от VPS.

Планы: не трогать, пока не сломается.

• Автор запустил личный блог на старом Google Pixel 5, питая его от солнечной панели и аккумулятора, чтобы продемонстрировать энергоэффективность и повторное использование техники.
• Участники отмечают, что современные ARM-смартфоны потребляют <5 Вт против 50–100 Вт у x86-сервера, что экономит до 800 кВт·ч в год.
• Обсуждаются риски: старые аккумуляторы при 24/7 работе могут «раздуться» и вызвать пожар, поэтому предлагаются варианты безбатарейного питания по USB-PD.
• Вопросы безопасности: Pixel 5 уже не получает обновлений, а Termux-окружение может ломаться из-за несовместимости пакетов.
• Некоторые считают идею интересной, но для статического сайта дешевле и надёжнее использовать GitHub Pages или S3.