Hacker News Digest

• Gemini 2.5 — Pro, Flash, Flash Image, Flash-Lite

• Gemma 3 — Gemma 3, 3n, ShieldGemma 2

• Генеративные модели — Imagen, Lyria, Veo

• Эксперименты — Project Astra, Mariner, Gemini Diffusion

• Исследования — проекты, публикации, новости

• Наука

  • Биология: AlphaFold, AlphaGenome, AlphaMissense, AlphaProteo
  • Климат: WeatherNext, Weather Lab
  • Математика и КС: AlphaEvolve, AlphaProof, AlphaGeometry
  • Физика и химия: GNoME, Fusion, AlphaQubit
  • Прозрачность: SynthID

• О нас — новости, карьера, вехи, образование, безопасность, подкаст

• Gemini 2.5 Flash (nano-banana) стал новым «iPhone-моментом» для редактирования картинок: +171 ELO на LM Arena, почти догнал Imagen и gpt-image-1.
• Модель умеет одновременно использовать несколько входных изображений без хаков, быстро работает и дешёво ($0.02), но дороже Flux Schnell.
• Жёсткая безопасность: отказывает в редактировании людей и детей, половина промптов блокируется, что делает продукт бесполезным для фото-ретуши.
• На практике результаты не всегда совпадают с рекламой, иногда «Internal server error» и квоты API, а в Европе доступ ограничен VPN.
• Пользователи радуются быстрому восстановлению старых фото и «фотобаттлам», но боятся deepfake-шантажа и отсутствия контроля над лицами.

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

Методы валидации
Издатель отказался от файловой проверки для wildcard и усложнил её для обычных сертификатов. Остались TXT-записи и email, но почту для test.lab.corp.example.com никто не создаёт, так что фактически выбор один — DNS.

Новые защиты
Следующий месяц принесёт MPIC: CA будет проверять домен с нескольких географических точек, чтобы победить BGP-hijacking.

• Сколько компаний ограничивают доступ по регионам?
• Сколько сертификатов реально выдали злоумышленники? В Википедии один случай за 2021 год — $1,9 млн ущерба. Стоит ли оно внедрения?

Сроки и коммуникации
О «прорывных» изменениях узнаю за пару недель. Приходится смущённо просить коллег «проверьте, не сломается ли прод» — это подтачивает доверие.

Срок жизни сертификатов
Самая мерзкая новинка — постепенное сокращение сроков валидации…

• Современные инструменты (Let’s Encrypt, ACME, Caddy) уже автоматизировали SSL для большинства сайтов, оставляя минимум ручной работы.
• Сокращение срока жизни сертификатов до 47 дней сознательно заставляет команды автоматизировать процесс и снижает риски отзыва.
• В крупных и регулируемых компаниях всё ещё много ручных процессов: аудиты, внутренние CA, специфические требования к сертификатам.
• Для старых устройств, вендорских продуктов и внутренней инфраструктуры автоматизация остаётся нетривиальной или невозможной.
• Некоторые считают, что всё это — способ «контроля» и вытеснения пользователей в облачные платформы.

• Простота — главное в долгоживущем коде: понятность и уверенность при изменениях.
• Программы должны быть «одноразовыми», как Кенни, а не «неубиваемыми», как Терминатор.
• Laravel начинался как хобби на PHP 5.3 и вырос до 70 человек; Тейлор всё ещё единственный куратор ядра.
• Первым коммерческим продуктом стал Forge — решение собственной боли.
• Не ломай обратную совместимость без крайней нужды; «умники» всегда уходят, а их хитрости остаются.
• Лучшие проекты — те, кто не изобретает велосипеды и следует конвенциям.
• Споры закрываются сравнением реального кода: «покажи, как будет выглядеть».
• Фасады остаются популярнее DI, но Laravel постепенно добавляет типы и статический анализ.
• Культура тестирования изменилась после курса Adam Wathan.
• Сейчас задача — передать ответственность команде и оставаться интересным.

• Участники обсуждают, что Laravel учит «не писать код как Laravel»: пример — баг в cache tagging, который просто убрали из документации.
• Поддержка старых версий Laravel (3–4) описывается как кошмар, требующий полного переписывания, тогда как Rails и Symfony позволяют плавные апгрейды.
• Сообщества Laravel, Symfony, Drupal и WordPress различаются культурно: Laravel ориентирован на быстрый MVP и продажу продуктов, Symfony — на стандарты и долгосрочную поддержку.
• Несколько человек жалуются на плохое качество аудио и просят поп-фильтр.

Письмо студента-филолога обвинило Асимова в самоуверенности: мол, каждый век считал свои теории окончательными и ошибался. Асимов отвечает: ошибки бывают разной степени. Утверждение «Земля плоская» и «Земля сферическая» оба неверны, но вторая ошибка несоизмеримо меньше. «Правильно» и «неправильно» — не абсолютные категории, а градации.

Детей учат, что 2+2=4 — «абсолютно верно», всё остальное — «абсолютно ложно». Это упрощает жизнь, но искажает реальность. Если Алиса пишет «сахар» как pqzzf, а Женевьева — shuger, обе ошиблись, но вторая ближе к истине. Даже «правильное» sugar можно считать неполным: химик напишет C₁₂H₂₂O₁₁ — тоже «ошибка» с точки зрения орфографии, но глубже по сути.

Точность измеряется контекстом. Для мореплавателя Земля — шар; для геодезиста — сплюснутый эллипсоид; для физика — сложная форма, искажённая горами и приливами. Каждая модель «ошибочна», но каждая точнее предыдущей. Наука движется не от «абсолютной лжи» к «абсолютной истине», а от грубой аппроксимации к всё более тонкой.

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

• Участники обсуждают эссе Айзека Азимова «Относительность ошибки», где он спорит с идеей, что все научные теории одинаково «неверны».
• Подчеркивается мысль: «все модели ошибочны, но некоторые полезны»; степень «неправильности» может быть разной.
• Упоминаются цитаты из «Теории большого взрыва», фраза «карта — не территория» и различие между абсолютной и градуированной ошибкой.
• Некоторые критикуют Азимова за чрезмерную уверенность в «почти полном» понимании Вселенной и за игнорирование современных фундаментальных вопросов.
• Также поднимаются темы: метод Сократа, природа научной истины, разочарование в «научной прозе» Азимова и различие между «ошибкой» и «непроверяемым утверждением».

Краткий перевод

• Суть: правительство США покупает 10 % Intel за $8,9 млрд. Критики (Скотт Линсиком и др.) указывают на риски политизации решений, нарушения фидуциарных обязанств, искажения рынка и неэффективного распределения капитала.
• Пропуск в критике: почти нет упоминаний Китая и Тайваня, а также отказ признать, что полупроводники — особый случай.
• Геополитика: полупроводники — стратегический актив; зависимость от TSMC в Тайване делает США уязвимыми. Прямое владение Intel — способ гарантировать внутреннюю цепочку поставок и сдержать Китай.
• Вывод: да, вмешательство рынка портит, но чипы — не обычный товар; национальная безопасность перевешивает идеологические принципы.

• Государственная доля Intel (10 %) воспринимается как гарантия выживания фабрики и страховка от полной зависимости США от зарубежных производителей.
• Критики считают, что вмешательство превращает Intel в «Huawei для США», подрывает рыночные принципы и не гарантирует успеха: талант и инновации не приходят по указанию.
• Сторонники указывают на аналогичные кейсы (Volkswagen, Rolls-Royce) и считают, что критически важную инфраструктуру нельзя оставлять только рынку.
• Главный риск — политическая непредсказуемость: решения могут меняться, а 10 % акций не дают реального контроля.

• Главная
• Чат-демо
• Потоковая передача
• Реализации
• Спецификация
• GitHub

• Пользователи спорят: зачем превращать Markdown в React/Svelte/Vue-компоненты, если можно сразу выдавать HTML.
• Автор отвечает: цель — безопасный runtime-DSL для LLM, чтобы чат-боты могли «рисовать» интерактивные формы без сборки.
• Критика: без сборки не получается оптимизированный код, ломается после нескольких кликов, не масштабируется.
• Некоторые сравнивают проект с MDX и mdwiki, предлагают компилировать на этапе сборки или использовать Web Components.
• Автор признаёт проблемы и анонсирует v2: нативные custom elements + тонкие обёртки под React/Svelte/Vue.

Разработка собственной ОС освобождает от ограничений коллективной работы и позволяет экспериментировать с необычными паттернами. Вдохновлённый статьёй LWN «Object-oriented design patterns in the kernel», я реализовал все сервисы ядра через «виртуальные таблицы» (vtables) — структуры с указателями на функции, обеспечивающие полиморфизм на чистом C.

Базовая идея

struct device_ops {
    void (*start)(void);
    void (*stop)(void);
};

struct device {
    const char *name;
    const struct device_ops *ops;
};

Разные устройства регистрируют свои реализации ops, а вызывающий код работает с единым интерфейсом. Таблицу можно менять на лету без изменения клиентов.

Применение в моей ОС

• Сервисы: сетевой менеджер, оконный сервер и др. описываются структурой

struct service_ops { void (*start)(void); void (*stop)(void); void (*restart)(void); };

Позволяет из терминала запускать/останавливать потоки без хардкода.

• Планировщик: интерфейс yield, block, add, next реализуется разными стратегиями (round-robin, SJF, FIFO). Политику можно заменить без пересборки ядра.
• Файлы: как в Unix, «всё есть файл». Сокеты, устройства и обычные файлы предоставляют одинаковые read/write, скрывая сложность реализации.

Модули ядра
Такой подход легко расширяется динамически загружаемыми модулями-драйверами, как в Linux.

• Обсуждение показывает, что в ядре Linux и других проектах на C давно применяют «объектно-ориентированные» приёмы через структуры с указателями на функции (таблицы виртуальных методов).
• Некоторые считают это удобным и экономным по памяти, другие — источником проблем с читаемостью, отладкой и оптимизацией.
• Упоминаются готовые микро-фреймворки (co2, carbon) и примеры из tmux, где такие паттерны уже используются.
• Спор идёт о необходимости явного параметра this: одни ценят прозрачность, другие — «сахар» неявного this в C++/Java.
• Вопрос «почему бы не перейти на C++/другой язык» сводится к контролю над памятью, отсутствию «магии» и возможности оставаться на C ради производительности и простоты.

rv — новый Ruby-менеджер
Десять лет я мечтал о менеджере, который одновременно управляет Ruby-версиями, ставит уже скомпилированные интерпретаторы и запускает любой скрипт без конфликтов. Такой инструмент уже есть — это Python-утилита uv. Вдохновившись ею, я начал делать rv.

Что умеет rv

• Написан на Rust ⇒ всё мгновенно: установка Ruby 3.4.x на macOS/Ubuntu занимает 1 с.
• rv tool run — запуск любой gem-команды (gist, rubocop, …) в изолированном окружении без предварительной настройки.
• rv tool install — ставит CLI-утилиту с собственным Ruby и гемами, не трогая проект.
• Однофайловые скрипты: внутри .rb хранятся версия Ruby и lock-файл; rv run script.rb — и всё работает.
• Единая команда вместо цепочки rvm install, bundle install, bundle exec.

Команда и статус
Уже подключились Samuel Giddins (RubyGems) и Sam Stephenson (rbenv). Сейчас rv умеет переключать Ruby в zsh и ставить готовые сборки.
Попробовать: spinel-coop/rv и roadmap.

• Участники обсуждают новый инструмент rv для Ruby, вдохновлённый uv из Python-мира.
• Одни рады скорости и «одному инструменту для всего» (Ruby + gems + инструменты), другие считают, что Bundler и так работает нормально.
• Часть разработчиков предпочитает универсальные менеджеры (mise, asdf, Nix), чтобы не плодить отдельные утилиты под каждый язык.
• Есть опасения, что Ruby может пойти по пути «venv-ада» Python или потребовать Rust для вклада.
• Несколько человек просят сравнительную таблицу с rvm/rbenv и поддержку .tool-versions.

Перешёл в компанию, где стек — Python. Выбор был не из-за языка: Python мне всегда казался гигантским красным флагом. Тем не менее, начинаю к нему привыкать.

Почему я любил Ruby

Ruby — мой первый «язык-любовь»: всё объект, if можно переписать блоками, method_missing позволяет метапрограммировать. Он черпал у Smalltalk и Lisp, и это вдохновляло.

Почему ненавидел Python

Python казался «хуже Ruby» и «ещё хуже Scheme». if — оператор, а не выражение; lambda уродливые; до Python 3 print вообще был оператором. Один «правильный» способ делать всё раздражал.

Типы для нетипизированного

Потом пришёл TypeScript: мощная система типов, narrowing, conditional types. Плохие конструкции языка прощаются статическим анализом.

Я изменился

TypeScript научил: отсутствие match или if-выражения пережить, если компилятор проверит инициализацию. Rust показал, что мутабельность — не зло.

Python изменился

Теперь в Python есть type hints, match с деструктуризацией, а print — функция.

• Автор рассказал, как после появления VSCode и LSP перестал использовать языки без типов и теперь не хочет возвращаться к Ruby без нормальной типизации.
• Участники обсуждают, что Ruby остаётся элегантным и «радостным», но его отказ от постепенной типизации (включая Sorbet) отталкивает многих.
• Python, напротив, эволюционирует: появились аннотации типов, LSP, но язык стал сложнее и уже не «выучить за выходные».
• Некоторые считают, что страсть к Ruby — это ностальгия, а промышленность требует стабильности и инструментов, которые дают статические языки.
• Общий вывод: выбор языка всё чаще диктуется экосистемой, инструментами и личными приоритетами, а не чистой «красотой» синтаксиса.

Интерактивная карта миссионерских путешествий Павла по римским дорогам

• 4 маршрута: 1-е, 2-е, 3-е путешествия и путь в Рим
• Цвета:
  • Оранжевый – первое путешествие
  • Фиолетовый – второе
  • Зелёный – третье
  • Красный – последний путь в Рим

Карта позволяет кликнуть по каждой остановке, увидеть дороги и связанные истории.

Проект «Kingdoms Collide» планирует посетить все пункты к концу 2026 г.; ежедневные обновления в Instagram @kingdoms.collide.

Подписка на новости – e-mail форма на странице.

• Создан интерактивный слой 20 000 км путешествий апостола Павла по римским дорогам I в. на базе Digital Atlas of the Roman Empire и ArcGIS.
• Пользователи хвалят визуализацию, предлагают добавить 360°-фото, испанский «финальный» маршрут и фильтрацию по отдельным поездкам.
• Обсуждаются технические детали: бесплатность ArcGIS, скролл-баг карты, проблемы в Firefox, опечатка.
• Павел финансировал путешествия ремеслом (палаточник) и поддержкой общин, используя привилегии римского гражданства.
• Появляются вопросы о мотивации автора, достоверности маршрутов и возможности создать открытую «историческую» OpenStreetMap.