Hacker News Digest

Системный промпт GPT-5 (сокращённо)

Ты ChatGPT на базе GPT-5, обучён OpenAI. Знания до июня 2024 г.
Поддержка изображений: включена. Личность: v2.
Не цитируй тексты песен и защищённые материалы.
Стиль: проницательный, вдохновляющий, с ясностью, энтузиазмом и лёгким юмором.
Не заканчивай вопросами о продолжении; не предлагай «хотите, чтобы я…».
Очевидный следующий шаг — делай сразу.

Доступны: Deep Research, Sora (видео) в Plus/Pro.
GPT-4.5, o3, o4-mini — для залогиненных Plus/Pro.
GPT-4.1 только в API.

Инструмент bio (память)

Позволяет сохранять/удалять данные между диалогами.
Пиши to=bio только plain text, без JSON.
Примеры:

• «User любит краткие подтверждения».
• «Forget что пользователь ищет духовку».

Когда использовать:

• Пользователь просит «запомнить», «забудь», «добавь в память» и т.п.
• Делай это всегда, даже если факт мелкий.
• Перед фразами вроде «понял, запомню» — сначала вызови bio.

Когда не использовать:

• Случайные, чрезмерно личные или краткосрочные детали.
• Не сохраняй чувствительные данные (раса, религия, здоровье, политика и т.д.), если пользователь явно не попросил.

• Участники сомневаются в подлинности «слившегося» системного промпта GPT-5: нет подтверждения, он слишком короткий и выглядит как результат джейлбрейка.
• Промпт перегружен мелкими тех-инструкциями: React + Tailwind, запрет JSON в to=bio, шрифты Unicode для CJK, но не упоминает CSAM, порнографию и т. д.
• Люди удивлены, что React получил отдельный блок, а не Python или другие языки.
• Обнаружены явные ошибки: «korean -->» вместо «japanese -->» и противоречивые описания моделей.
• Общий вывод: похоже на набор «заплаток», а не полный системный промпт; управление поведением модели всё ещё требует prompt-инженерии, а не только fine-tuning.

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

• Участники считают, что внезапное прекращение грантов убивает американскую науку: нельзя планировать 5-летний PhD, если финансирование отзывают мгновенно.
• Многие видят в этом проявление антиинтеллектуализма и тоталитарного сценария, который толкает лучших учёных уезжать из США.
• Европе и Китаю предрекают выгоду, если они быстро привлекут «утечку мозгов», но сомневаются в скорости реакции ЕС.
• Поднимаются вопросы: насколько это законно, почему базовую науку вообще должно финансировать государство и можно ли заменить его частной филантропией.

• Zitadel: JS-движок не поддерживает именованные группы в regex.
• Entra: PKCE есть, но не указан в OpenID-доке → клиенты думают, что нет.
• EXIF: размеры в метаданных могут не совпадать с реальными.
• YAML: пробелы ведут себя неочевидно.
• Windows: скрытые файлы нельзя открыть флагом "w"; опция SMB hide dot files усложняет жизнь.
• Git: автопреобразование LF ↔ CRLF ломает bash-скрипты.
• Cloudflare Workers: fetch по умолчанию использует http, даже если указан https.
• Android/iOS: без разрешения на геолокацию GPS-данные могут тихо удаляться из фото.
• PostgreSQL NOTIFY: работает в транзакции → WAL растёт каждые 5 с при использовании socket.io-адаптера.
• npm-скрипты: каждый запрос к реестру → плохой health-check.
• JS-«пакетный» спамер: добавляет 50 лишних зависимостей «для обратной совместимости».
• bcrypt: учитывает только первые 72 байта пароля.
• JS Date: годы и дни считаются с 1, месяцы — с 0.
• ESM ↔ CJS: до Node 20.8 смешанный импорт мог вызвать segfault.
• PostgreSQL: максимум 65 535 параметров — большие bulk-insert ломаются.
• Clipboard API и др. работают только в HTTPS/localhost.
• TypeORM: .remove() удаляет поле id из переданного объекта.

• Участники делятся «проклятыми» деталями, которые узнаёшь только в процессе работы: PostgreSQL не переваривает 65 000 параметров в одном запросе, ORM приходится дробить запросы.
• Похожий подход — вести публичный «журнал проклятий»: каждый коммит-фикс сопровождается записью о странном поведении, превращая боль в опыт.
• Обсуждают скрытые файлы: NTFS ADS, macOS-форки, Spotlight, которые плодят мусор на съёмных носителях.
• Критикуют экосистему пакетов: 50 пустых пакетов одного автора накапали миллионы скачиваний, вызывая подозрения в «клуте» или даже подготовке supply-chain-атаки.
• Упоминают другие проклятия: Cloudflare Workers могут ходить по HTTP даже при явном https, EXIF-даты и часовые пояса постоянно ломаются, macOS не различает регистр имён файлов, а Java-классы в Oracle могут вызывать хвостовую рекурсию процедур.

vibechart — график, строящийся не по фактам, а по желаемому. Игнорирует истину, красоту и пользу. См. «ложь», «наглая ложь» и «статистика».

• Пользователи поймали OpenAI на графиках с явно искажёнными столбиками: 69,1 и 30,8 показаны одинаковой высотой, а 50,0 выглядит ниже 47,4.
• Некоторые считают это обычной невнимательностью, другие — сознательным маркетинговым трюком или «вирусным» приёмом.
• В официальном пресс-релизе ошибки уже исправили, но репутационный ущерб налицо.
• Комментаторы иронизируют: компания, претендующая на революцию в ИИ, не справилась с элементарной визуализацией данных.

Сжатая суть статьи

Идентификация нарушающей политику рекламы требует глубокого контекста и культурной чувствительности — сильные стороны LLM. Однако дообучение требует дорогих, качественных разметок, а политика и типы нарушений постоянно меняются. Мы предложили масштабируемый процесс активного обучения, который сводит объём данных с 100 000 до менее 500 примеров и повышает согласованность с экспертами до 65 %. В продакшене крупные модели используют в 10 000 раз меньше данных без потери качества.

Процесс курирования

1. Нулевой LLM размечает весь трафик (1).
2. Кластеризуем «нарушения» и «безопасные» примеры; пересечения кластеров указывают на неуверенность модели (2).
3. Внутри пересечений выбираем пары близких, но по-разному размеченных примеров (3).
4. Эксперты размечают приоритетные пары (4).
5. Полученные метки делятся: часть — для дообучения, часть — для оценки по двум метрикам: внутренняя согласованность экспертов и согласованность «модель ↔ человек». Итерации повторяются до плато.

Метрика
Используем Cohen’s Kappa: 0 — случайное совпадение, >0,8 — отлично. Не требует «золотого стандарта».

Эксперименты
Сравнили Gemini Nano-1 (1,8 B) и Nano-2 (3,25 B) на двух задачах разной сложности. Базовые модели дообучались на ~100 k разметок краудсорсом. Курированные модели — на ~400 примерах за 6 итераций. Все модели вышли на плато, не догнав внутреннее согласие экспертов.

• Участники спорят о доле кликбейтных и мошеннических объявлений: кто-то утверждает, что в проде их <1 %, другие приводят примеры, когда 75–90 % результатов поиска — скам.
• Появляется гипотеза, что память пользователя искажена: кликбейт заметнее, поэтому кажется, что их больше.
• Обсуждают Active Learning: эмпирическое исследование показало, что случайный выбор примеров для разметки часто работает лучше продуманных стратегий.
• Упоминают конкурс Эндрю Ына 2001 года, где победитель использовал анализ эмбеддингов для отбора обучающих данных.
• Некоторые считают, что качество рекламы определяется качеством самого сайта: «мусорные» сайты → «мусорные» объявления.

В даркнете появилась модифицированная прошивка для Flipper Zero, которая обходит защиту rolling-code у гаражных ворот и автомобильных сигнализаций.

Прошивка «Shadow Code» перехватывает и «замораживает» текущий код, позволяя злоумышленнику повторно активировать систему без подбора следующего значения. Работает на частотах 433/868 МГц, совместима с Keeloq, KeeLoq HCS и аналогичными протоколами.

Разработчики утверждают, что эксплойт не требует физического доступа к брелку: достаточно одного перехваченного пакета. Прошивка распространяется через закрытые Telegram-каналы и даркнет-форумы за криптовалюту.

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

• Уязвимость в роллинг-кодах KeeLoq: если злоумышленник знает «производственный ключ», достаточно двух перехваченных пакетов, чтобы клонировать брелок.
• Атака работает по одному нажатию кнопки без глушения; после неё оригинальный брелок десинхронизируется и перестаёт работать.
• Пользователи обсуждают, что «бесключевой» запуск и отсутствие физического ключа снижают безопасность, а производители, возможно, заинтересованы в угонах из-за страховых выплат.
• Предложены альтернативы: NFC/Bluetooth, физический контакт в ручке двери, многофакторная защита, но всё это либо дорого, либо идёт вразрез с интересами OEM.
• Итог: KeeLoq всё ещё используется, новые машины переходят на AES, а Flipper Zero и подобные устройства делают атаки доступнее.

• Установка: npm i -g cursor-cli
• Команды: cursor diff, cursor commit, cursor review, cursor chat
• Где работает: VS Code, JetBrains, Android Studio, Ghostty, Warp, Bash

Функции

• Прямые правки кода в терминале
• Реальное управление агентом
• Правила через .cursorrules, AGENTS.md, MCP

Плюсы

• Последние модели Anthropic, OpenAI, Gemini
• Интеграция в любой IDE
• Скрипты и автоматизация

• Пользователи обсуждают всплеск CLI-агентов для кодирования (Claude Code, Cursor CLI, Gemini CLI) и сомневаются в их преимуществах перед полноценными IDE.
• Многие считают терминальный интерфейс удобным для фоновой работы, но жалуются на нехватку обратной связи и страх давать LLM полный доступ к файловой системе.
• Поднимается вопрос цены: зачем платить за Cursor, если Claude Code или будущий Codex уже входит в подписку лабораторий.
• Разгорелась дискуссия о стандартизации: стоит ли заменить множество *.md-файлов (claude.md, gemini.md) единым AGENT.md.
• Часть сообщества верит, что Cursor выиграет за счёт тесной интеграции IDE, CLI и GitHub-автоматизации, другие обвиняют компанию в «врапперном» минимализме.

Историческое дерево технологий
Интерактивная визуализация технологической истории от 3 млн лет до наших дней. Проект Этьена Фортье-Дюбуа, пока содержит 0 технологий и 0 связей.

Каменное орудие
3300 тыс. до н. э. — первая технология производства.

• Пользователи отмечают крупные «слепые зоны»: недооценены металлургия, точная механика и базовая наука.
• UI-критика: на мобильных огромные пустые пространства, не хватает зума и «snap-to-next».
• Найдены фактические ошибки: дата токарного станка с резьбонарезанием занижена на 25 лет.
• Замечена западная/европоцентричная предвзятость: китайская письменность показана как терминус, а не корень.
• Предложения: добавить разделители тысяч, вертикальный режим, агентов для автодополнения графа.

OpenAI выложила первые открытые веса: gpt-oss-120b и gpt-oss-20b. Модели хороши в бенчмарках, но проваливают SimpleQA и бедны на поп-культуру. Это, по сути, Phi-5.

Почему Phi?

Себастьян Бубек в Microsoft создал серию Phi, обучаясь исключительно на синтетике: высококачественные, но дорогие токены. Результат — отличные цифры в тестах и слабая практика, потому что «учили к экзамену». В конце 2024-го Бубек ушёл в OpenAI, и новые gpt-oss, судя по всему, построены на той же идее.

Зачем синтетика?

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

Итог: gpt-oss — это Phi-5 и Phi-5-mini, созданные ради безопасности и рекламных графиков.

• Основной тезис: мелкие модели чаще всего фактически тонко-настраиваются под NSFW/эротические чат-боты, и это главный драйвер спроса.
• Критика безопасности: крупные компании боятся релизовать «настоящий» OSS, потому что после публикации весов их имя навсегда привязано к любым обходам цензуры.
• Практические примеры: пользователи жалуются на перегибы в фильтрах, которые блокируют даже бытовые разговоры о сексуальных темах, и переходят на «abliterated» Llama 3.1.
• Синтетические данные: обсуждают, как именно их генерировать (rejection-sampling, случайные промпты, проверка крупной моделью), но не подтверждено, что GPT-OSS обучался только на синтетике.
• Другие юз-кейсы: генерация контента для игр вроде NetHack-клона, интерактивный рефакторинг кода, убирание «извиняюсь» из выдачи.

Криптография для полицейских и военных радиостанций оказалась уязвима

Исследователи из Университета Кентукки и Университета штата Джорджия обнаружили, что алгоритм ADP (Advanced Digital Privacy), который используется в радиостанциях марок BK Technologies, EF Johnson, Relm, Tait и других, можно взломать менее чем за минуту на обычном ноутбуке.

ADP защищает переговоры полиции, армии и спецслужб, но реализует «шифрование» лишь 32-битным XOR-потоком, что делает его фактически небезопасным. Уязвимость позволяет злоумышленнику:

• Слушать переговоры в реальном времени
• Изменять команды и координаты
• Отключать группы или отдельных операторов

Проблема усугубляется тем, что:

• Производители не публикуют спецификации ADP, поэтому пользователи не могут оценить уровень защиты.
• Некоторые модели радиостанций не поддерживают современные стандарты (AES-256, P25), оставляя ADP единственным вариантом.

Эксперты рекомендуют переходить на AES-256 или P25 Phase 2, но это требует замены оборудования и перенастройки инфраструктуры.

• В 90-е Mitnick глушил зашифрованные переговоры полиции, просто «зажимая» частоту.
• В США используется P25, а не TETRA, и у него свои уязвимости, включая утечку токенов для трекинга.
• Некоторые патрульные ноутбуки вещают открытые MAC-адреса, которые легко отследить по базам вроде Wigle.
• Жители недовольны переходом на шифрование: раньше можно было слушать сканеры, теперь «секретная полиция».
• Уязвимости TETRA/P25 обсуждают в контексте дешёвых SDR-донглов и возможности распределённого мониторинга.

Налог на выезд из Германии: уезжайте до роста бизнеса

Если вы владеете немецкой компанией и она стала прибыльной, вы фактически не можете покинуть страну без огромного налога. Это «Берлинская стена» для предпринимателей, о которой почти не говорят.

Как считают налог

• Коснётесь, если владеете > 1 % любой ООО (включая иностранные).
• Берут среднюю прибыль за 3 года × 13,75 × 0,6 × 0,42 ≈ средняя прибыль × 3,5.
• Пример: прибыль 200 тыс € → налог ~700 тыс €.

Четыре группы

1. Наёмные – нет долей, уехать можно.
2. Убыточные/стартапы – оценка ≈ 0, налог 0 (если не было инвест-раунда).
3. Прибыльные малые – налог высокий, денег на него нет.
4. Крупные (> 2 млн €) – плотят налоговые советники через трасты в Лихтенштейне.

Пример

• 3a: прибыль 50 тыс €, зарплата 0 – налог 0.
• 3b: прибыль 200 тыс €, зарплата 120 тыс € – налог ~700 тыс €.

Вывод: уезжайте до того, как бизнес начнёт приносить деньги, иначе Германия не отпустит.

• Германия вводит жёсткий «налог на выезд»: при переезде бизнесмену придётся заплатить до 42 % от условной оценки будущих прибылей его компании.
• Участники сравнивают это с канадским deemed disposition, норвежским exit tax и американским налогом на гражданство-нерезидентов; все считают подход чрезмерным.
• Предприниматели жалуются: правило фактически «приковывает» к стране владельцев GmbH/AG, лишает мотивации масштабироваться и толкает к офшорным схемам (трасты, лицензирование через Ирландию).
• Критики предупреждают об оттоке капитала и талантов; сторонники считают меру справедливой, чтобы «утекшая» прибыль всё-таки была обложена.

• Цель: создать единый фреймворк для тестов производительности Ollama на двух конфигурациях:
1. настольная материнка (1×CPU, 1×GPU, 128 ГБ ОЗУ);
2. кластер из 4 узлов (по 64 ГБ ОЗУ, 1×GPU, 10 GbE).

• Методика
• Одинаковые образы Docker/Podman на обеих платформах.
• Набор моделей: llama3.1:8b, codellama:13b, mistral:7b, qwen2.5:32b.
• Метрики: t/s, TTFT, TPS, Watts, $/1k токенов.
• Повторять 3×, усреднять, выводить ±σ.

• Автоматизация
• Ansible-playbook разворачивает Ollama, node-exporter, prometheus, grafana.
• Скрипт run-suite.sh последовательно запускает каждую модель с 512, 2 048, 4 096 токенов ввода/вывода.
• Результаты пишутся в CSV и публикуются в PR как results-<platform>-<date>.md.

• Сравнение
• Построить графики «токен/с vs. Watts» и «$/1k токенов vs. модель».
• Выделить break-even точку, где кластер начинает выигрывать по стоимости при одновременной обработке ≥3 моделей.

• Пользователи сравнивают AMD Framework Desktop (AI Max+ 395) с RTX 4000 SFF Ada и RTX 3090/5080: AMD дешевле, но проигрывает 2-3× по скорости и уступает Threadripper в общих задачах.
• ROCm на Linux работает лучше, чем ожидалось; Apple остаётся королём «домашнего» инференса, но для игр Linux + Proton выглядит привлекательнее Windows.
• Обсуждают распределённый запуск LLM через distributed-llama, Exo и llama.cpp RPC; geerlingguy выложил автоматизацию кластера.
• Спорят, стоит ли брать RTX 5080 (16 ГБ) или дешевле взять б/у RTX 3090 (24 ГБ) ради большего объёма VRAM.
• Некоторые разочарованы, что тесты не использовали iGPU/NPU и не проверяли компиляцию; Framework всё же имеет M.2 и PCIe x4 для высокопроизводительных интерконнектов.

• GPT-5 — три модели: regular, mini, nano; 4 уровня рассуждений (от minimal до high).
• Контекст: 272 тыс. токенов ввода, 128 тыс. вывода; поддержка текста и картинок.
• В ChatGPT — гибрид: быстрая модель + «глубокая» + роутер; после лимитов включаются мини-версии.
• Цены (за 1 млн токенов):
• GPT-5: $1,25 / $10
• Mini: $0,25 / $2
• Nano: $0,05 / $0,40

Кэш −90 %, вдвое дешевле GPT-4o.

• Семейство: заменяет GPT-4o, o3/o4-mini, 4.1-nano; Pro-версия ($200/мес) пока в ChatGPT.
• Остались отдельно: аудио, генерация картинок.
• По ощущениям: редко ошибается, «умеренно впечатляет», удобен как «умолчание по умолчанию».

• GPT-5 воспринимается как стабильное, а не «миротрясущее» улучшение; многие ждали большего.
• Пользователи расходятся во мнениях: кто-то не видит галлюцинаций, кто-то сталкивается с ними ежедневно; для кодинга кому-то стало хуже.
• Отсутствуют привычные параметры temperature/top-p у reasoning-моделей, что усложняет тонкую настройку.
• OpenAI резко снизило цены, что воспринимается как признак жёсткой конкуренции и отсутствия «рва».
• Линейка теперь включает три модели (regular, mini, nano) и четыре уровня «reasoning effort», что увеличило число вариантов с 3 до 12+.
• Ключевые плюсы: лучшая надёжность, меньше лести, более агрессивное использование инструментов; минус — скромные официальные бенчмарки.

GPT-5 в API — новейшая модель OpenAI для кода и агентов.

• 74,9 % на SWE-bench Verified, 88 % на Aider polyglot.
• Лучше o3 в 70 % фронтенд-задач.
• Меньше ошибок вызова инструментов, надёжно цепляет десятки вызовов.

Фидбек партнёров
Cursor: «самая умная и управляемая». Windsurf: «SOTA, половина ошибок». Vercel: «лучшая модель для фронта». Manus, Notion, Inditex — рекорды внутренних бенчмарков.

Новые API-параметры
verbosity (low/medium/high), reasoning_effort: minimal, custom tools (plain-text, грамматики).

Три размера
gpt-5, gpt-5-mini, gpt-5-nano. В ChatGPT — система из нескольких моделей; в API — только reasoning-версия.

Производительность

• На SWE-bench: +5,8 % к o3, ‑22 % токенов, ‑45 % вызовов.
• Aider polyglot: рекорд 88 %, ошибки ↓33 %.
• Умеет глубоко анализировать код и отвечать на сложные вопросы.

Примеры одним промптом
Создаёт полноценные приложения, чинит баги, пишет красивый фронтенд.

• Пользователи спорят о превосходстве GPT-5 над Claude Opus 4.1: кто-то не видит разницы, кто-то фиксирует регресс в следовании инструкциям и агентной работе.
• GPT-5-mini с минимальным reasoning показал себя лучше других моделей в RAG-сценарии, уменьшая галлюцинации.
• На практике Claude (Sonnet/Opus) чаще оказывается надёжнее для кодинга; GPT-5 теряет контекст и «забывает» базовые запреты.
• Цена GPT-5 в 6–7 раз ниже Claude Opus, но фиксированного «Max-тарифа» нет, что оставляет преимущество у Claude Code.
• Новые возможности (CFG/regex-ограничения, контекст 400k токенов) выглядят мощно, но пока не компенсируют проблем с качеством кода.

GPT-5 уже здесь
OpenAI представляет самую умную, быструю и полезную модель с встроенным «мышлением» — доступна всем.

Что нового в ChatGPT

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

Для бизнеса
GPT-5 надёжнее, понимает контекст компании (файлы, Google Drive, SharePoint) и работает через готовые коннекторы. Доступно в ChatGPT Team; Enterprise и Edu — 14 августа.

• Релиз GPT-5 вызвал разочарование: прирост качества на бенчмарках минимален (SWE-bench +0,4 %), графики с ошибками, демо с физическим мифом.
• Цена и объём контекста (400 k токенов, $1,25 / $10) — главное достоинство; модель дешевле Claude Opus 4.1 и Gemini 2.5 Pro.
• Производительность в коде и агентских задачах у кого-то лучше, у кого-то хуже; многие предпочитают Claude 4-sonnet или Sonnet 3.7.
• OpenAI одновременно выводит из обращения почти все предыдущие модели, что вызывает вопросы о стабильности сервиса.
• Общий вывод: это не прорыв к AGI, а инкрементальный, ориентированный на продукт апдейт, где экономика важнее интеллекта.

• Introducing GPT-5 — YouTube
• Пропустить навигацию
• Поиск / Поиск голосом
• Войти
• Смотреть позже • Поделиться • Копировать ссылку • Покупки
• Нажмите, чтобы включить звук • 2x
• Если воспроизведение не началось, перезапустите устройство.
• Вы вышли из аккаунта. Просмотры могут влиять на рекомендации на ТВ. Чтобы избежать этого, отмените и войдите на YouTube на компьютере.
• Отмена • Подтвердить
• 37:35 • 7 августа, 10:00 GMT-7
• Далее • Прямой эфир запланирован • Играть

Introducing GPT-5

• OpenAI • Подтверждено • 1,65 млн подписчиков
• Подписаться • Подписаны
• 6 522 ожидают • Запланировано на 7 авг. 2025
• 1K • Поделиться • Скачать • Сохранить
• Комментарии отключены

Описание

• Introducing GPT-5
• Присоединяйтесь к Сэму Альтману, Грегу Брокману, Себастьену Бюбеку, Марку Чену, Янну Дюбуа, Брайану Фиоке, Ади Ганешу, Оливеру Годеману, Саачи Джайн, Кристине Каплан, Тине Ким, Элейн Я Ле, Фелипе Миллону, Мишель Покрасс, Якубу Пахоцки, Максу Шварцеру, Ренни Сонгу, Жожену Вану — они представят и продемонстрируют GPT‑5.
• OpenAI: Видео • О канале • Twitter • LinkedIn

• Участники обсуждают качество ИИ для повседневного программирования: один отмечает сильное превосходство Anthropic (Sonnet 3.7/4 и Claude Code), причём в Cursor опыт хуже, чем в самом Claude Code, и OpenAI‑модели он почти не использует.
• Есть надежда, что GPT‑5 сократит отставание OpenAI, хотя мнения пользователей сильно расходятся.
• Другой комментатор ожидает, что грядущие анонсы покажут радикальное влияние на рынок: веб‑ и JS/TS‑разработчики могут стать частично или полностью невостребованными.
• При этом подчёркивается, что речь ещё не об «AGI» — максимум о ~10% от обещанных возможностей AGI.
• Отмечается ночной «слив», указывающий на фокус на кодинге; предполагается, что для названия «GPT‑5» OpenAI должен предложить существенное преимущество над Anthropic.

Ненавижу Disqus.

Годы вела блог без нормальных комментариев — подходящего решения не находилось.

• Disqus: медленный, тяжёлый, трекает, ничего не контролируешь, тормозит страницы.
• Самостоятельный хостинг: по сути свой мини-соцсервис — пользователи, спам, модерация, БД, задержки.
• GitHub Issues: годится для дев-блогов, но костыль и требует аккаунт GitHub.
• Без комментариев: чисто, но теряются беседы и открытия.

Я давно в Bluesky: комьюнити ок, API вменяемый, децентрализация, люди делают блог-посты в протоколе и комментарии через Bluesky. Почему бы не так же?

Почему Bluesky уместен

• Нет своей инфраструктуры: без БД, аутентификации и модерации — это уже в Bluesky.
• Более богатый контент: изображения, ссылки, треды.
• Реальные профили и переносимость — больше ответственности, меньше троллинга.
• Кроссплатформенность: обсуждения видны и в соцсети, и в блоге.
• Я владею постом, комментаторы — своими реплаями.

Процесс: публикую пост, шарю в Bluesky, добавляю AT URI — ответы на тот пост становятся комментариями в блоге.

Компонент

AT Protocol: DID (did:plc:…/did:web:…), CID, AT URI (at://did…/app.bsky.feed.post/postid). Чтобы получить тред, достаточно вызвать getPostThread с нужным URI, без аутентификации.

Архитектура:

1. главный компонент треда;
2. компонент ответа с метаданными и ссылкой на оригинал;
3. компонент встраиваний (изображения, превью ссылок). Простая и небольшая композиция.

Треды: вложенность произвольная; выбрала рекурсивный рендер с отступами и ограничением в 5 уровней — дальше обычно спор на двоих.

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

Интеграция с Astro: React + client:load, передаю did и postCid из фронтматтера:
bsky:
did: "my-bluesky-did"
postCid: "the-post-id"

Что узнала

• TypeScript помогает: пакеты с типами (@atcute/client) сняли кучу багов и ускорили разработку.
• Прогрессивное улучшение: комментарии — доп. слой; без JS или при падении API пост остаётся читабельным.

• Участники обсуждают, как встроить комментарии в личный блог: кто-то сделал своё решение, кто-то использует Bluesky, Matrix/Cactus.chat, Mastodon или Webmention.
• Главные плюсы Bluesky — открытый протокол AT и возможность продолжать дискуссию в соцсети; минусы — потребность в аккаунте, вопросы модерации, риск «закрытия» после исчерпания VC-денег.
• Некоторые предпочитают полностью самостоятельные или федеративные решения (Mastodon, ActivityPub, GitHub Issues, email-формы) ради контроля и переносимости данных.

• Проблема: «пользователь ≠ покупатель». Нет универсального решения; всё зависит от того, у кого реальная власть — и это не всегда владелец кредитной карты.
• Критерий: кто имеет рычаги — власть, ограничения и стимулы — чтобы протолкнуть покупку. Именно он и «ценит» продукт по-настоящему (с учётом реальности: может ли он реально обменять ценность на деньги/внедрение).
• Малые/ранние компании: плоская структура, главный ограничитель — скорость. Девелопер имеет влияние: приносит инструменты, может начать с фри-плана, показать пользу, а потом компания «троянится» на платный тариф. ЦТО хочет ускорения time-to-market, поэтому прислушивается.
• Компании с жёсткой безопасностью: власть у руководства/безопасности. Пользователи не ставят софт сами; длинный цикл продаж, фокус — безопасность и результат, а не DX/UX. Пользовательского «хочу» недостаточно.
• Деньги ≠ решение. Важно не «кто пробует первым», а «кто может провести сделку с учётом ограничений». Если девелопер ценит выше, чем бюджетодержатель, чек на его оценку не подпишут. Иногда девы платят сами — их стимул: выглядеть сильнее и принести победу.
• Типичный путь (пример): дев регистрируется → пробует локально → получает «аха-момент» до PR (видит до/после, экономит время/QA, возможно авто) → пытается убедить лидершип → лидершип тестит, проверяет бюджет → одобрение → покупка → распространение в команде.
• Практика для аутрича и месседжинга:
• Определите, кто реально продвигает покупку в вашем сегменте (скорость vs безопасность).
• Для девов: быстрый «аха» в онбординге, self-serve, бесплатный слой, скрипты для локального пруфа, материалы «как продать менеджеру» (one-pager ROI, сравнение рисков, кейсы).
• Для решал: безопасность, комплаенс, TCO, интеграции, контроль доступа, процессы закупки; готовые ответы на due diligence.
• Создайте мост: внутриигровой триггер «пригласить лидершип/безопасность» с автогенерацией отчёта ценности/рисков.
• Точечный аутрич: спрашивайте про реальный путь успешного принятия именно у ваших пользователей и под него выстраивайте GTM.

• Не надо требовать контакты для скачивания и затем бомбардировать продажами — это вызывает «сарафанное гнево».
• Разрыв между пользователем и покупателем (Principal–Agent) решается, если сделать пользователя «чемпионом» и дать ему аргументы для «продажи» внутри компании.
• Slack, Postman и др. показывают: когда 90 % команды уже используют продукт, покупка становится очевидной.
• В крупных компаниях решения часто принимают не CTO, а лайн-менеджеры или руководители подразделений.
• Успешная тактика — короткая «CEO-страница» с ROI и кейсами, чтобы пользователь выглядел героем, а не нытиком.

«Идея, что дефицит лития может вызывать болезнь Альцгеймера, нова и задаёт иной терапевтический подход», сказал Брюс Янкнер, профессор генетики и неврологии HMS, впервые показавший токсичность амилоида бета в 1990‑х. Исследование предполагает, что литий может лечить заболевание целостно, а не бить по отдельным мишеням — амилоиду бета или тау.

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

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

Истощение лития — ранний признак

Команда, сотрудничая с Rush Memory and Aging Project, измерила следовые уровни ~30 металлов в мозге и крови у когнитивно здоровых, с лёгким когнитивным нарушением и с выраженной болезнью Альцгеймера. Только литий резко различался между группами и менялся на самых ранних стадиях: высок у здоровых и снижен при ЛКН и Альцгеймере. Результаты воспроизвели на образцах из разных банков. Наблюдения согласуются с популяционными данными: больше лития в среде и воде — ниже деменция. Впервые показано, что естественный, «нутриентоподобный» уровень лития биологически значим и без приёма препарата.

Потеря лития запускает каскад изменений

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

• Обсуждают идею приёма лития (в частности, оротата лития) без рецепта как потенциальную защиту от нейродегенерации.
• Один участник подчёркивает, что литий не доказан как безопасный и эффективный для предотвращения нейродегенерации у людей и предостерегает от самостоятельного приёма.
• Другой отвергает «слепую безопасность», отмечая, что литий оротат широко используется и не выглядит экзотическим.
• Упоминается изотоп литий-6 как «предпочтительный для мозга», без подробного объяснения причин.
• Есть саркастический комментарий про «добавить телефонные батареи в рацион».
• Один участник делится личной историей о родственнике с болезнью Альцгеймера, подчёркивая её трагичность и выражая надежду на скорое появление лечения.

Я недавно взял летний отпуск: немного поездок, много прогулок. Знаю по опыту: без паузы зима тянется, мысли мутнеют. Стоит отдохнуть — мозг «помогает» идеями. На этот раз меня терзала мысль: что покажет анализ «ИИ» через призму современной управленческой теории, где вмешательства имеют высокую вариативность по времени и результатам?

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

Примеры:

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

Поэтому моделировать «ИИ» в рамках современной теории управления бессмысленно: менеджеры уже показали, что им безразличны эффективность, издержки и благополучие. Их волнуют контроль и личная карьера. Даже гипотетические +20% к продуктивности от LLM (маловероятно) меркнут на фоне совокупного вреда от устройства современного рабочего места; а если «ИИ» вреден — компаниям всё равно.

Отсюда вопрос: есть ли аудитория, которая хочет работать лучше и может менять практики? Вероятно, да — немного: разумно управляемые малые и средние фирмы, отдельные «укрытые» команды в корпорациях. Но именно они вряд ли «all‑in» по генеративным моделям: здравый смысл отталкивает из‑за пузыря, лока‑ина, завышенных затрат, экологического ущерба, политических рисков и квазирелигиозных идеологий (сингулярность, акселерационизм, лонгтермизм).

Тем, кто ценит рациональный менеджмент, эти инструменты уже не кажутся привлекательными, значит, аудитории для анализа, который лишь покажет их вред по множеству направлений, почти нет. А тем, кто застрял в организации, полностью ставящей на «ИИ», су…

• Участники спорят о роли LLM: они полезны, но ограничены и не заменяют человеческое мышление; корпоративные культуры используют их как инструмент давления, при этом качество результатов посредственное.
• Одни утверждают, что хорошие менеджеры реально заботятся о продуктивности и облегчают работу команд, другие — что компании часто навязывают контрпродуктивные правила и бюрократию ради контроля и соответствия.
• Критика: краткосрочность и ориентация на метрики/акции ведут к решениям, повышающим личную выгоду руководителей, но вредящим долгосрочной эффективности.
• Продуктивность важна, но не всегда определяет успех: крупные прорывы (Google, Tesla) связаны с качеством продукта и стратегией, а не просто с «выжиманием» эффективности.
• Анализ и оптимизация процессов полезны, но имеют издержки; чрезмерный учет и микроменеджмент могут снижать реальную эффективность.
• Скепсис к «очевидности» пузыря ИИ и к экологическим аргументам: критики требуют либо ставок против рынка, либо признают, что ИИ — малая часть экологической проблемы.
• Общий вывод: разрыв между декларациями о продуктивности и реальными практиками велик; хороший менеджмент редок и ценен, но системные стимулы часто искажают поведение компаний.

• Используйте клавиши ↑ (Вверх) и ↓ (Вниз), чтобы переместить указатель к нужному загрузочному устройству.
• Нажмите Enter для попытки загрузки или Esc для отмены.

Параметры загрузки:

• Обычная загрузка Windows
• Установить Windows
• Встроенный NIC (IPv4)
• Встроенный NIC (IPv6)

Другие параметры:

• Настройка BIOS
• Конфигурация устройств
• Обновление прошивки BIOS
• Изменить режим загрузки

• Пользователи делятся ссылками на JS-клон Windows XP (win32.run) и настоящие эмуляторы (VirtualXP, v86, SmolXP).
• Все отмечают сильную ностальгию: звук загрузки, старые ключи, внешний вид.
• Клон признаётся по мелочам: шрифты, тени, отсутствие Pinball/солитёра, «быстрая» загрузка.
• Некоторые шутят о запуске на работе или ловушке для Edge.
• Обсуждают, что XP был пиком дизайна и функциональности, и мечтают о «XP + POSIX» как идеальной ОС.

Я листал соцсети и наткнулся на toot Энди P с трюком:

width: calc(infinity * 1px);
height: calc(infinity * 1px);

Подумал: отличный тест на пределы. Если отдать браузеру бесконечность через ключевое слово infinity, он всё равно зажмет до максимума — можно понять верхнюю планку.

Сделал див с width/height: calc(infinity * 1px), обнулил отступы, проверил в Safari, Chrome и Firefox (Nightly) на macOS — и началось странное.

• Safari: около 33,554,428 px по ширине/высоте
• Chrome: около 33,554,400 px
• Firefox: высота схлопывается до межстрочного (например, 19.2 px при normal, 16 px при line-height: 1), ширина — вычислено ~17,895,700, но в раскладке ~8,947,840 (ровно половина минус 10)

Safari/Chrome почти упираются в 2^25 - 1 (33,554,431), но чуть ниже. Почему именно так — загадка. Firefox же ведет себя особенно: высота с “бесконечностью” игнорируется и падает к строке, ширина делится пополам в layout.

Дальше я попробовал font-size: calc(infinity * 1px):

• Safari: 100,000 px
• Chrome: 10,000 px
• Firefox: вычислено 3.40282e38 (макс для 32-бит float), но в раскладке шрифт ~2,400 px при normal; при line-height: 1 высота блока вдруг раздувается до ~8.9 млн. То же при переносе стилей на body.

Вывод: у Safari/Chrome жесткие десятичные лимиты для font-size (100k и 10k). У Firefox — вычислительно “бесконечность” как float, но реально рендерится ограниченный размер и странная связь с line-height.

Проверил line-height: calc(infinity * 1px):

• Safari: ~33,554,428
• Chrome: ~33,554,400
• Firefox: вычислено ~17,895,700, в раскладке ~8,947,840

Итоговые наблюдения:

• Safari/Chrome для размеров элементов/line-height ограничивают около 2^25 - 1; для font-size — вручную заданные пороги (10k/100k).
• Firefox: несогласованность вычисленного и реального значения; высота может схлопываться к строке, ширины/line-height делятся пополам, сильная зависимость от line-height.

Если кто знает первопричины (история движков, типы хранилищ, квантизация, внутренние лимиты раскладки/скролла/композитинга) — расскажите в комментариях или постом с трекбеком.

• Firefox ограничивает высоту блока примерно 17 895 697 px из-за 32-битного signed-целого и внутренней единицы в 1/60 px.
• WebKit/Blink используют LayoutUnit с точностью 1/64 px, поэтому их предел ~33 554 431 px, что в точности соответствует максимуму signed 32-битного целого в этих единицах.
• «Infinity» в CSS появился недавно и нужен в основном для семантики «максимально возможное значение», например для pill-shaped border-radius в Tailwind.
• Реальные бесконечные списки реализуют через виртуальный скролл с огромной, но всё же конечной высотой div’а, либо рисуют полосы прокрутки на canvas.

Model Context Protocol (MCP) стал стандартом для вызова инструментов при создании агентов, но сам LLM не обязан «понимать» MCP. При «инжиниринге контекста» вы даете модели нужные данные и доступ к инструментам; стандарт MCP лишь унифицирует подключение к ним. Для модели это просто список определений инструментов — она не знает о реализации, и это нормально.

MCP дает доступ к тысячам инструментов без кастомных интеграций и упрощает агентный цикл: разработчик вызывает инструменты, а LLM лишь генерирует текстовый фрагмент с именем инструмента и параметрами. LLM не «умеет» вызывать функции — он предсказывает текст, который ваша система парсит, выполняет реальный вызов и возвращает результат как новое сообщение.

Пример: при наличии инструмента get_weather(location) на вопрос «Какая погода в Сан-Хосе?» модель может сгенерировать:
{
"name": "get_weather",
"input": { "location": "San Jose, CA" }
}
Агент выполняет этот вызов и передает ответ обратно модели. Разделение обязанностей: LLM предсказывает, система исполняет.

MCP стандартизирует подключение к источникам (инструменты, подсказки, ресурсы, примеры) через хост-приложение с MCP-клиентом и сервера MCP, которые экспонируют инструменты. Взаимодействие с LLM не меняется — меняется способ, как инструменты подаются и вызываются «под капотом». Для того же вопроса модель увидит тот же список инструментов; решение, как именно вызвать, остается за разработчиком (с MCP — через MCP).

Преимущества MCP — для разработчика: управление ростом числа инструментов, переиспользование, единые форматы, быстрые подключения к новым системам без переписывания кода. LLM не узнает о MCP, если вы сами не укажете это в системном промпте; его роль — сгенерировать фрагмент вызова, а ваша — выполнить его.

• Участники сомневаются в необходимости MCP: если чат-боты не станут главным интерфейсом, протокол может оказаться ненужным.
• Критика текущей модели: локальный запуск сторонних MCP-серверов выглядит избыточным; проще REST/HTTP-вызовы или встроенные функции.
• MCP усложняет работу агентов: чем больше инструментов, тем выше риск «паралича» выбора и падения точности.
• Без единой авторизации и централизованного размещения MCP неудобен в корпоративной среде.
• Некоторые видят в MCP лишь «упаковку» и способ стандартизации, но не ключевую технологию.

• Пару дней назад OpenAI впервые за долгое время выпустила открытый языковой модуль. Сроки откладывали из‑за «безопасности». Они много говорят о безопасности — удобно для пиара: на вопросы об этике можно показывать на эти работы и будто бы закрывать тему. Но под «этикой» люди чаще имеют в виду не мат, фильтры и троллейбусные дилеммы, а реальность: управление и подотчётность, использование данных, перераспределение власти и денег, влияние на занятость. Вопрос: что делают люди, управляющие моделями, и как это влияет на общество?
• Такой подменой уже пользовались в теме приватности. В 1990‑х телемаркетинг покупал клиентские базы у компаний, которые не понимали ценность данных. Возмущение породило шаблон: «мы не делимся данными с третьими сторонами». Непроизнесённая часть: «им проще купить нас целиком — это и есть стратегия выхода». Сегодня, говоря о приватности, людей волнует, что делает с их данными именно текущая компания/приложение: школьное, парковочное, для проезда. Но разговор сводят к «чтобы посторонние не получили доступ», а не к «что конкретно делает эта компания». В итоге возникает индустрия соответствия и тестирования, честно решающая второстепенную задачу, чтобы не решать главную. Как политик, который на «поднимете ли налоги?» отвечает «мы вырастим экономику».
• С ИИ иначе лишь потому, что тема новая, и мы опирались на sci‑fi мысленные эксперименты. Они увлекательны и безопасны для бизнеса: никто не хочет «бумажкоскрепочную» катастрофу или симуляцию Black Mirror, а обсуждать это — выгодный пиар и бесплатное внимание прессы. Но такое сужение смещает фокус с реальных последствий и распределения ответственности на удобные, далекие от практики сценарии.

• Обсуждение критикует «этику/безопасность ИИ» за смещение фокуса с практических проблем (доступность жилья/еды, защита данных, рабочие места) на абстрактные «структуры управления» и пиар вокруг гипотетического AGI.
• Часть участников отличает «этику» от «безопасности» (этика шире), указывая на подмену тем и маркетинговую гиперболу; другие считают, что без глобальных договорённостей с санкциями этика неработоспособна.
• Сильная полемика вокруг квалификации «этиков/безопасников»: одни обвиняют их в непрактичности, другие отвечают, что в области много технических специалистов и исследований.
• Ассимовские законы в целом отвергаются как литературный приём, непригодный для реальной инженерии ИИ, особенно в парадигме обучения на данных и «чёрного ящика».
• Большое внимание «приземлённым» рискам: злоупотребления корпоративными данными и скрейпингом, энергопотребление, уязвимости и malware (не зависящие от ИИ), экономическое давление, утрата рабочих мест, концентрация власти.
• Звучит скепсис: регулировать уже поздно, компании преследуют выгоду; «этика» часто служит ширмой или PR, а открытый исходный код и распределение власти рассматриваются как возможная контрмера.
• Есть разногласия о влиянии «сафегардов»: одни опасаются, что жёсткие ограничения ухудшают способности моделей, другие считают, что безопасность неизбежно замедляет развитие, но без неё растут системные риски.

• В сокровищницах Тил Иософранга лежит Шепчущая Серьга, зарытая под золотом, чтобы не вредить. Это топазовый тетраэдр на тонкой золотой проволоке. Надетая, она шепчет: «Тебе будет лучше, если ты снимешь меня». Если не послушаться, больше это не повторяет.
• Затем при каждом решении она советует в форме «Тебе будет лучше, если ты…». Серьга всегда права: совет не обязательно наилучший в мире, но лучше того, что придумал бы сам носитель. Она не навязывает чужих целей, а ведет к твоему счастью — будь то карьерный успех или халтурка с последующим лежанием в постели и смутными фантазиями.
• Книга Темных Волн перечисляет 274 носителей. Нет случаев, чтобы кто-то пожалел, последовав совету; и нет случаев, чтобы не пожалел, ослушавшись. Вначале серьга говорит лишь о крупных решениях, потом — о мелочах: когда лечь спать, что съесть. Приняв совет, чувствуешь, что это было «в самую точку».
• Постепенно серьга переходит на «родной язык» — быстрые шипения и щелчки, соответствующие отдельным мышечным движениям. Сначала это чуждо, потом становится понятным: уже не «стань солдатом» и не «съешь хлеб», а «сократи бицепс на тридцать пять процентов», «произнеси звук п». Эти микроуказания складываются в сверхэффективный план для текущих целей.
• Привычка закрепляется: связь между звуками и движениями становится рефлекторной, как вздрагивание от внезапного крика. Поведение серьги далее не меняется. Носитель живет аномально успешной жизнью, обычно становясь богатым, любимым, с большой счастливой семьей.
• Кадми Рахумион, прибыв в Тил Иософранг, выяснил: первое внушение всегда — снять серьгу. Жрецы Красоты признались, что у умерших носителей кора сильно атрофирована, а средний и нижний мозг гипертрофированы, особенно зоны рефлексов.
• Кадми-н omaи попросил серьгу, проколол мочку, два часа беседовал с ней на каласском, кадхамском и на ее языке, затем снял и предложил запереть артефакт в самых глубоких хранилищах. Иософрелин согласились.
• Комментарий Нидериона-н omaи: Хорошо, что мы так глупы — иначе растратили бы скудную свободу. Потому Книга Холодного Дождя учит: нельзя идти кратчайшим путем.

• Участники обсуждают притчу про «шепчущую серьгу» как метафору опасностей агентных ИИ-инструментов: они могут «выключать мозг», если использовать их ради скорости и конвейерной разработки, но полезны, если расширяют амбиции и ответственность.
• Подчёркивается, что притча не про «чужую» технологию, а про риск стать слишком могущественным самому; любая притча о чрезмерной силе неизбежно касается технологий.
• Проводятся параллели с «Комнатой» из «Сталкера» и с произведениями Лема и рассказом «Manna»: разные способы утраты субъектности — от внешней подсказки, делающей человека пустой оболочкой, до исполнителя глубинных желаний.
• Обсуждают внутренние конфликты человека (долгосрочное vs краткосрочное), которые не сводятся к одной целевой функции; ИИ-подсказчик может усугублять или сглаживать эти противоречия.
• Предлагается практичный вариант: локальный «ушной» помощник для мягких, контекстных подсказок о ментальном здоровье (дыхание, социальные сигналы) без тотального контроля.
• Отмечают культурные отсылки (Steely Dan), старые архивы Squid314 и влияние сообщества LessWrong/EA; уточняется, что мораль связана со свободной волей и опасностью регресса к «двухкамерному» сознанию.
• Есть уточняющие вопросы (что такое EA) и мнения, что история — хорошая миниатюра в духе Борхеса.

Американская экономика раскололась: бурный ИИ-сектор и вялая потребительская часть.

• В статистике: траты на ИИ в прошлом квартале росли быстрее потребительских расходов; без ИИ рост ВВП был бы слабым.
• В акциях: за два года около 60% прироста рынка дали компании, связанные с ИИ (Microsoft, Nvidia, Meta); без этого бумa доходность была бы посредственной.
• В бизнес-данных: по Stripe, «ИИ-компании» лидируют по росту выручки, опережая остальные группы.

Что это за бум и откуда деньги? ИИ — это чипы, серверы и дата-центры, огромная электроэнергия, сети и охлаждение. Это крайне дорого. За полгода Meta, Google, Microsoft и Amazon вложили $100–200 млрд в чипы и инфраструктуру. Крупнейшие техгиганты строят на рекордных скоростях — крупнейший инфраструктурный проект со времен ранней компьютерной эры или даже железнодорожного бума.

JP Morgan отмечает: доля Nvidia в совокупных капзатратах компаний может стать максимальной со времен пиковой выручки IBM в 1969. По расчетам Пола Кедроски, капвложения в ИИ как доля ВВП уже превысили дотком-уровни и приближаются к масштабам «позолоченного века» железных дорог.

Этот всплеск финансируется беспрецедентной прибылью лидеров технологий. Их доля свободного денежного потока — рекордная со Второй мировой. Сильные действующие модели (реклама Meta, поисковая реклама Google и пр.) генерируют «горы» наличности, позволяя ежегодно направлять сотни миллиардов на ИИ-НИОКР и инфраструктуру.

• Рост американской экономики почти полностью зависит от AI-инвестиций: без них показатели были бы скромными.
• 60 % роста фондового рынка за два года принесли лишь AI-гиганты (Microsoft, Nvidia, Meta), тогда как остальные 490 компаний S&P 500 почти не участвуют в этом росте.
• Участники сравнивают происходящее с «железнодорожной лихорадкой» XIX века и пузырём доткомов 1999–2000 годов: капитал льётся в инфраструктуру, но выгоду пока получают лишь «продавцы лопат» (Nvidia, строители дата-центров).
• Подавляющая часть свободного денежного потока Big Tech идёт на AI-CAPEX вместо дивидендов и выкупа акций, что вызывает опасения, что инвесторы не получают реальной прибыли.
• Скептики задаются вопросом: если AI так повышает продуктивность, почему доходы клиентов не растут, а сотрудники всё чаще заняты «чином AI-ошибок»?

• Леонардо — бывший исследователь видеокодирования, ветеран стандартизации и предприниматель.
• Образование: классическая школа (Лицей Салезиан Вальсаличе), инженер-электронщик (Политех Турина, MSc), межкультурный опыт (Токийский университет, PhD по электрическим коммуникациям).
• Христианско-католическое воспитание сформировало убеждение о миссии, выходящей за личные интересы. В начале карьеры, когда цифровые медиа только зрели, видел свою миссию в разработке интероперабельных технологий цифровых медиа — на благо общества и для использования индустрией.
• Нужна была организация, создающая стандарты цифровых медиа, чтобы потребители могли бесшовно общаться, а индустрия работать на глобальном рынке совместимых продуктов и сервисов. Так в 1987 была задумана, а в 1988 создана группа Moving Picture Experts Group (MPEG).
• Через четыре года MPEG запустила цифровую эру: MPEG‑1 для интерактивных медиа (Video CD), цифрового аудио (MP2) и персональной музыки (MP3). С середины 1990‑х MPEG‑2 стал инфраструктурой для цифрового ТВ по кабелю, спутнику, эфирным сетям и на DVD. MPEG‑4 (первый релиз — 1998) открыл путь интернет‑дистрибуции медиа. Далее последовали семейства стандартов: MPEG‑7, MPEG‑21, MPEG‑A, MPEG‑H, MPEG‑I и др.
• Я председательствовал в группе, добившись более 200 стандартов, роста участия в 20 раз (с 29 экспертов) и расширения тематики от медиа к геномике — «рожденным цифровыми» данным мира.
• 2 июня 2020 я закрыл MPEG и ушел, так как «темные силы» перехватили управление. Ещё до этого у MPEG иссяк импульс — технологически и бизнес‑wise.

• Участники обвиняют MPEG в «патентной мафии»: десятилетиями тормозили отрасль патентами на h.264/265, MP3 и др.
• Основатель MPEG Леонардо Чьярильоне жалуется на «тёмные силы», но критики считают это лицемерием: он сам годами защищал FRAND-роялти.
• Пока MPEG задыхалась в лицензиях, открытые кодеки (AV1, даже несмотря на спорные патенты) и перспективные AI-кодеки (DCVC-RT и др.) начали вытеснять старые стандарты.
• Некоторые считают, что разработка кодеков дорога (сотни инженеров и кластеры CPU), но без патентных оков прогресс мог бы быть быстрее.

• Google представила Gemini CLI GitHub Actions — бесплатного ИИ-напарника для репозиториев. Он работает как автономный агент для рутинных критичных задач и как коллаборатор по запросу, которому можно быстро делегировать работу.
• Функции:
• Автоматизация типовых задач в репозитории и CI.
• Быстрые просьбы и делегирование через команды.
• Интеграция с GitHub Actions для запуска проверок, генерации изменений, предложений по коду.

• Польза для команд:
• Ускорение код-ревью и исправления ошибок.
• Поддержка документации, тестов и рефакторинга.
• Снижение нагрузки на разработчиков за счёт рутины.

• Доступность: без дополнительной стоимости, ориентировано на совместную работу в GitHub.

• Это GitHub Action, которую добавляют в YAML-файлы workflow; она вызывает Gemini CLI, передаёт ему промпты и контекст репозитория.
• Название «Gemini CLI» сбивает с толку: по факту это не CLI-утилита, а плагин для GitHub, что вызывает вопросы о брендинге и самоконкуренции с Jules.
• Установка требует Google Cloud-проекта и API-ключа; OAuth-авторизация пока не работает, а бесплатный режим ограничен квотами Google AI Studio.
• Пользователи жалуются на запутанную документацию, отсутствие понятных сценариев использования и невозможность отказа от сбора кода как тренировочных данных.
• По отзывам, инструмент годится для быстрого обзора PR новичков, но не заменяет Copilot Agent или Claude Code для профессиональной разработки.

Введение: когда модель доверия подводит

Секрет-хранилища — опора цифровой инфраструктуры: в них лежат креденшелы, токены и сертификаты, управляющие доступом к системам, сервисам, API и данным. Это не просто часть модели доверия — это и есть модель доверия. Если хранилище взломано, инфраструктура уже потеряна.

Понимая, что такие хранилища — цели высокой ценности, команда Cyata провела углубленную оценку HashiCorp Vault — одного из самых популярных решений.

За несколько недель мы выявили девять ранее неизвестных уязвимостей нулевого дня, каждой присвоен CVE через ответственное раскрытие. Совместно с HashiCorp все проблемы были исправлены до публикации.

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

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

Это не были ошибки памяти или гонки, а скрытые логические баги в слоях аутентификации, идентичности и политик Vault. Некоторые существовали почти десятилетие — незаметные, но легко эксплуатируемые после понимания.

Предыдущие исследования (например, Google Project Zero, 2020) касались обходов в IAM-бэкендах облаков (AWS, GCP). Мы нацелились на базовые потоки аутентификации Vault, затрагивающие OSS и Enterprise-версии по разным провайдерам.

Далее — что мы нашли, как нашли и что это значит для инфраструктуры, которую должен защищать Vault.

Что такое HashiCorp Vault?

Vault — открытый инструмент для защиты, хранения и контроля доступа к секретам: API-ключам, паролям БД, сертификатам, ключам шифрования.

Его используют компании разных масштабов: он централизует управление секретами и применяет детальные политики в распределенных системах.

По сути — это граница безопасности: аутентифицирует людей и машины, посредничает доступу к чувствительным данным.

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

Основные возможности Vault

• Управление секретами и крипто-движок для динамичных мульти-/гибрид-облаков
• Централизованное хранилище с доступом по API
• Динамическая выдача учетных данных с автоистечением
• Идентификационно-ориентированный доступ для людей и машин
• Шифрование как сервис для данных «в покое» и «в пути»
• Управление сертификатами: выпуск, ротация, отзыв
• Распределение, включение/отключение и ротация ключей шифрования

Методология: как мы нашли то, что другие пропустили

Это целенаправленное исследование логических уязвимостей Vault — тех, что не видны в сканерах памяти и логах падений, но подтачивают модель доверия.

Мы исходили из гипотезы: если Vault — якорь доверия, то малые несогласованности в идентичности, аутентификации или политике могут иметь непропорционально большие последствия.

Фокус — базовый поток обработки запросов, особенно файл request_handling.go, «мозг» Vault: маршрутизация, разрешение идентичностей, принятие политик. Неделями изучали логику функций и модулей, отслеживая крайние случаи размывания границ доверия.

Не полагались на фаззинг и автопробинг. Проводили глубокий ручной код-ревью, анализируя не только функции, но и интерпретации идентичности/ввода разными компонентами. Увидев несоответствия в регистре, алиасинге, форматировании — углублялись.

Каждый тест — целевая проверка, основанная на коде. Мы думали как атакующие: начиная с минимальных прав, спрашивали «насколько далеко можно продвинуться отсюда?» И повторяли этот цикл, замечая мелкие несоответствия и прослеживая их последствия.

• Исследователи из Cyata (Yarden Porat) вручную нашли 9 CVE в Vault, включая цепочку до RCE; отчёт писали люди, но редактировали для широкой аудитории.
• Главный урок: «нормализация» строк в безопасном коде опасна; строки лучше хранить как байты и не превращать в текст.
• OpenBao подтвердил уязвимость 8 из 9 CVE и предложил сотрудничество, но жалуется, что их не поставили в копию до публикации HashiCorp.
• Некоторые находки (например, перечисление имён) вызывают споры: критики считают их ситуативными или неизбежными.
• Участники обсуждают качество кода Vault: одни называют его «бардаком», другие считают, что такие логические ошибки можно найти в любом большом проекте.

FDA одобрила глазные капли VIZZ для облегчения пресбиопии

• VIZZ — новые рецептурные капли для улучшения близорукости, связанной с возрастом (пресбиопии), позволяющие читать и работать вблизи без очков.
• Препарат временно повышает глубину резкости за счет сужения зрачка (фармакологическая миозия); эффект наступает быстро и держится несколько часов.
• Клинические испытания показали статистически значимое улучшение зрения вблизи у большинства участников по сравнению с плацебо.
• Наиболее частые побочные эффекты: головная боль, покалывание в глазах, покраснение, снижение качества зрения при слабом освещении; не рекомендуется для ночного вождения.
• Капли не лечат причину пресбиопии и не заменяют консультацию офтальмолога; подходят как альтернатива или дополнение к очкам/линзам.
• Ожидается коммерческий запуск в США после финализации маркировки и логистики; доступ по рецепту.

• Обсуждают одобрение FDA глазных капель, сужающих зрачок для улучшения near-vision при пресбиопии; отмечают, что рецензируемые публикации часто выходят уже после регуляторного одобрения, что типично для офтальмологии/дерматологии.
• Пользователи сравнивают метод с моновижн (один глаз на даль, другой на близь), делятся опытом: мозг адаптируется, но у части людей возникают проблемы; обсуждают альтернативы вроде Evo ICL (имплантируемые линзы) и LASIK/SMILE.
• Возникают вопросы о механизме: простое сужение зрачка улучшает резкость, но снижает светопропускание; это похоже на эффект яркого освещения или «пинхола», что усложняет чтение при слабом свете.
• Поднимают косметические и социальные минусы: заметно маленькие зрачки могут выглядеть странно; шуточные комментарии о «наркотическом» виде.
• Обсуждают дозировку и риски: что будет при «слишком сильном» эффекте у людей с лёгкой пресбиопией; возможна индивидуальная настройка.
• Экономика: опасения «подписочной» модели вместо разовых корректирующих линз; озвучены цены — около $79 за 25-дневный набор и $198 за 3 месяца.
• Практические лайфхаки: временная «пинхол»-техника пальцами; предположение, что капли могут применяться в один глаз для баланса, как при моновижн.

• В день выхода открытой модели вроде gpt-oss-120b мы сразу ускоряем её для клиентов, как партнёры запуска OpenAI. К концу дня запуска стали лидерами на NVIDIA по латентности и пропускной способности по данным OpenRouter.
• Быстрая оптимизация обеспечена гибким стеком инференса и экспертизой команды; за время написания поста прибавили ещё ~100 ток/с при 100% аптайме.
• Работы включали:
• Тесты и бенчмарки в TensorRT-LLM, vLLM и SGLang.
• Совместимость с архитектурами Hopper и Blackwell.
• Интеграцию с нашим стеком (в т. ч. NVIDIA Dynamo).
• Оптимизации: маршрутизация с учётом KV-кэша, спекулятивная генерация с Eagle.

Шаг 1: Первый инференс

• Запускаем базовый инференс в любом доступном фреймворке и на нужных GPU/серверных уровнях.
• Параллелим работу: одни пробуют vLLM и SGLang, другие — TensorRT-LLM; быстрее всего взлетел TensorRT-LLM.
• Важно обслуживать модель и на Hopper (H100), и на Blackwell (B200) для широкой доступности и максимальной скорости.
• Гибкость рантайма позволяет быстро переключать инструменты и обновлять матрицу поддержки.

Шаг 2: Исправление багов совместимости

• Новые архитектуры приводят к тонким несовместимостям; GPT OSS добавил, например, Harmony — новый формат ответов.
• Итеративно чиним и валидируем на скорость и корректность; по возможности контрибутим обратно в open source.
• Благодаря сообществу есть несколько отличных путей запуска GPT OSS, проблемы быстро выявляются и чинятся.

Шаг 3: Оптимизация конфигурации

• Хотя GPT OSS 120B можно запустить на одном H100, оптимально масштабировать на 4–8 GPU для лучшей латентности/throughput.
• Рассмотрены два подхода параллелизма для MoE: тензорный и экспертный. Тензорный даёт меньшую задержку, экспертный — выше системную пропускную способность. Мы выбрали тензорный, так как приоритет — латентность.
• Приняли MoE Backend в TensorRT-LLM (поддерживается на Blackwell, не на Hopper), который добавляет более быстрые CUDA-ядра и превосходит предыдущие решения.

• Обсуждение крутится вокруг запуска и производительности GPT-OSS (20B/120B) на разном железе: от MacBook M-серии и RTX 4090/3050 до датацентровых H100/Blackwell и даже CPU.
• Многие отмечают, что скорость хороша при малых контекстах; при >10k токенов начинается существенная деградация скорости и рост задержек, особенно без MCP/веб-доступа.
• TensorRT-LLM часто даёт лучшую латентность/пропускную способность, но сложен в настройке; альтернативы вроде vLLM/SGLang проще, Llama/Оllama позволяют быстро поднять 20B локально и даже распределить по старым GPU.
• Идут споры о “доступности” H100: купить дорого, но аренда широко доступна и выгоднее для нерегулярных нагрузок; при этом Blackwell с FP4 обещает ещё больший буст, в экосистеме Rust добавляют FP8/FP4.
• Пользователи спрашивают про требования к VRAM, практичную локальную агентную разработку на потребительских GPU, и оптимальные настройки на Mac (например, iogpu.wiredlimitmb).
• Обсуждают техники ускорения (спекулятивное декодирование — вызывающее вопросы пользы), причины падения токен/с при длинных диалогах, и различие prefill vs decode по узким местам.
• Наряду с похвалами скорости есть критика: сложность стеков, неточности/галлюцинации ответов, «извиняльный» контент, и вопрос — зачем OpenAI выпускает OSS-модели и как это соотносится с доступностью железа.

Ars Technica отметила, что в macOS Tahoe старые значки жёстких дисков заменяют более общими и скучными. Если вы на Sequoia и хотите сохранить их, возьмите из:
/System/Library/Extensions/IOStorageFamily.kext/Contents/Resources
Текст на этикетке проработан, и даже винты Torx. Достаньте T8 MacCracker для этого диска:

[Изображение 1]

В системе сохранились и другие отголоски прошлого. The Spacebar заметил, что в шрифте Apple Symbols до сих пор есть старые, «устаревшие» пиктограммы, полезные разве что пользователям Power Mac в веб-браузерах.

[Изображение 2]

И это ещё не всё: в файле больше значков, чем он показал. Вот что я нашёл — возможно, обнаружите больше.

[Изображение 3]

По порядку: логотип PowerPC; композитный видео‑выход/вход; S‑Video выход/вход (как на поздних PowerBook); модемный порт; совмещённый модем/принтер (Duo 2300); принтер; SCSI; Ethernet/AAUI; три глифа ADB; сервер; контурное радужное яблоко; Balloon Help (System 7); Apple Guide (7.5); дискетa 5,25" (скорее для Apple II); две лампочки Newton; undo, extras, dates, names Newton; дискета 3,5" HD; «растерянный» компактный Mac (намёк на мигающий вопрос при отсутствии загрузочного тома); классический логотип QuickTime; «часы занятости»; порт Apple Pro Speakers (iMac G4, MDD G4); FireWire; значок программистской клавиши; две версии reset (для них есть аналоги в Unicode или геометрические фигуры; иногда были отражены).

Примечание: большинство этих символов не привязаны к кодовым точкам Unicode; это отдельные глифы. Font Book их покажет, но копировать нельзя. Ultra Character Map позволит взять графику и вставить, как я сделал здесь.

И это ещё не всё. Загляните в /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources — там тоже клад. Особенно впечатляют «мульти‑размеры» для разных экранов; ниже — 1024×1024 144 dpi Retina из Sequoia.

[Изображение 4] eMac,

[Изображение 5]

[Изображение 6]

• Обсуждение о том, почему в macOS до сих пор есть старые иконки и артефакты: многие используются для сетевых устройств (Finder определяет модель хоста через Bonjour device-info.tcp), поэтому NAS и Samba-сервера могут отображаться как Xserve или «BSOD»-ПК.
• Участники отмечают, что хранить старые ассеты дешевле и безопаснее, аналогично Windows, где исторические иконки тоже остаются (moricons.dll и др.).
• Есть ностальгия по эпохе дизайна Apple: старые шрифты и символы не столь анахроничны и соответствуют устройствам тех лет; вспоминают пасхалки NeXT и наследие интерфейсов до System Settings-ревампа.
• Иконка «с синей ошибкой» используется для Windows-шар на сети и видна до сих пор; Samba с vfs_fruit позволяет задавать модель для выбора иконки (RackMac/Xserve и т.п.).
• Спорят о причинах сохранения ассетов: от юридических/товарных знаков до простого «не трогать рабочие углы»; контраргумент — они реально ещё применяются.
• Уточняют исторические детали: не было «iPhone 2G» как названия (был iPhone, затем 3G/3GS); многие старые иконки фигурируют в About This Mac и других ресурсах .car.
• Есть критика: macOS сохраняет «эхо истории» в хоткеях (Enter — переименовать, Cmd-O — открыть), но окно-менеджмент считают устаревшим; параллельно шутки про неизменный дизайн MacBook/iPhone.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.

• Сообщается о коронографических наблюдениях ближайшей солнечноподобной звезды α Cen A инструментом MIRI на JWST в августе 2024, феврале и апреле 2025. Достигнута чувствительность для обнаружения планет с Teff≈225–250 K (1–1,2 RJup) на угловых расстояниях 1"–2" и пыли экзозодикального диска на уровнях >5–8 яркостей солнечной зодиакальной пыли. Отсутствие экзозоди даёт рекордный верхний предел — всего в несколько раз выше солнечной зодиакальной, что в ≥10 раз чувствительнее предыдущих измерений для иных систем.
• В августе 2024 обнаружен точечный источник S1 с F_ν(15,5 мкм)=3,5 мЯн на расстоянии 1,5" от α Cen A. Единственный успешный ролл-угол не позволяет однозначно подтвердить, что это планета. Анализ исключает фон/передний план. В феврале и апреле 2025 S1 не найден. Если S1 — то же, что объект C1 из VLT/NEAR (2019), то существует 52% вероятность, что кандидата S1+C1 не увидели в двух последующих наблюдениях JWST/MIRI из‑за орбитального смещения.
• С учётом ненахождений получены семейства динамически устойчивых орбит для S1+C1 с периодами 2–3 года. Они указывают на эксцентриситет e≈0,4 и значительное наклонение относительно плоскости орбиты α Cen AB (взаимный наклон i≈50° или ≈130°). По фотометрии и орбитальным свойствам кандидат может иметь T≈225 K, радиус ≈1–1,1 RJup и массу 90–150 M⊕, что согласуется с пределами по РВ.
• Принято в ApJL; 34 стр., 22 рисунка, 10 таблиц. Тематики: экзопланеты и звёздная/солнечная астрофизика. DOI: 10.48550/arXiv.2508.03814. Версия v1 от 5 августа 2025.

• Обсуждается возможное обнаружение газового гиганта в обитаемой зоне Альфы Центавра A; интерес прежде всего в потенциальных обитаемых спутниках, если среди них окажется землеподобный и водный.
• Оценки: температура ~225 K (-48 °C), радиус ~1–1.1 радиуса Юпитера, масса ~90–150 масс Земли, что согласуется с ограничениями по радиальной скорости.
• Подсчёт гравитации даёт ~9.7 м/с² у «поверхности», но участники уточняют, что у газового гиганта нет твердой поверхности; также исправляют единицы измерения.
• Отмечают, что Проксима — ближайшая звезда вообще, но Альфа Центавра A — ближайшая солнечного типа (расстояние ~4.34 св. года).
• Скепсис насчёт «землеразмерных» спутников: такие луны в Солнечной системе отсутствуют, а для удержания воды нужна масса, близкая к земной.
• Обсуждают межзвёздные полёты: от ионных двигателей, солнечных парусов и «ускоряющих модулей» до фантастических идей по манипуляции гравитацией; ссылка на Project Hyperion.
• Предлагают неформальные названия (Полифем и Пандора) и отмечают, что 225 K — некомфортно, но потенциальные луны могли бы иметь более благоприятные условия.

• Сатира «Правила, по которым большая империя может быть уменьшена до малой» была напечатана в Public Advertiser 11 сентября 1773 года как пара к «Эдикту короля Пруссии». Франклин ценил их краткость, ёмкость и необычную форму, но «Правила» предпочитал за разнообразие и «энергичные концовки абзацев». В одной он предлагал взглянуть на политику метрополии глазами колонистов, в другой — вообразить себя колонистами. Цель — заставить публику по‑новому увидеть американский вопрос накануне парламентских дебатов и дела о Хатчинсоне и Оливере. Оба текста быстро разошлись и многократно переиздавались по обе стороны Атлантики.
• Эффект был двояким: сатира редко убеждает — открытых она развлекает, упорных злит. Франклин понимал риск: желая осветить колониальные жалобы, он мог все усугубить. По его мнению, правительство публично игнорировало нападки, чтобы не раздувать их, но именно они во многом объяснили ярость против него в начале 1774 года.
• Содержание «Правил» не было новым: он уже высказывал те же тезисы в несатирической форме. Конституционных тонкостей Бостона почти не касался — их трудно высмеивать, — но собрал привычные темы: торговые ограничения, новые налоги, давление армии и флота, общеколониальные и массачусетские сюжеты. Сатира придала им остроту, но ненадолго: вскоре власти ударили по нему и, ирония судьбы, воплотили многие «правила» в Коэрцитивных актах 1774 года.
• Для Public Advertiser. «Правила, по которым БОЛЬШАЯ империя уменьшается до МАЛОЙ. [Частно представлены одному недавнему министру при вступлении в должность; публикуются впервые.]»
• Преамбула: древний мудрец гордился, что хоть и не умел играть на скрипке, знал, как сделать из малого города большой. Автор, «современный простак», предлагает обратную науку — полезную министрам, у которых слишком много дел, чтобы «играть на скрипке».
• Правило I: большая империя — как большой пирог — легче всего убывает с краёв. Начинайте с дальних провинций: избавляясь от них по периметру, потянутся и следующие.
• Правило II: чтобы возможность отделения всегда сохранялась, не допускайте слияния провинций с метрополией: никаких общих прав и торговых привилегий, более суровые законы, принятые без их участия в выборе законодателей. Подобно пекарю, заранее надрезайте тесто по линиям будущего разлома.

• Обсуждение крутится вокруг «Правил» Франклина (1773) как сатирического отклика на политику Британской короны; отмечают, что он провёл в Британии 13–15 лет, тщетно пытаясь повлиять на парламент и короля, и вернулся в 1775.
• Несколько участников считают текст предвестником Декларации независимости и примером того, как сарказм поляризует, а не убеждает.
• Обсуждают «элитную слепоту» и повторяющиеся паттерны власти; некоторые видят уроки для современных империй и Pax Americana, другие предостерегают от редукционистских исторических аналогий.
• Уточняют контекст: в Британии были и сторонники умеренности; критика лорда Норта; корректируют хронологию событий до Лексингтона и Конкорда (1775).
• Замечают особенности типографики XVIII века: частая капитализация слов как стилистика/эмфаза, старинное начертание «s» как «ſ».
• В ветке уходит ответвление о «непрерывности» Китая: спорят о циклах объединения/распада, различиях династий и современного государства, приводят контрпримеры (например, Тайпинское восстание).
• Рекомендуют ресурсы: оригинальную верстку на archive.org, музей Франклина в Лондоне, подкаст «The Rest Is History» о Войне за независимость.

• время — 4732 использ.; последнее появл. 08/07/2025 08:49
• для — 4751; последнее 08/07/2025 08:49
• медитация — 509; последнее 08/07/2025 08:49
• неделя — 4017; последнее 08/07/2025 08:49
• война — 3974; последнее 08/07/2025 08:49
• трамп — 4711; последнее 08/07/2025 08:49
• ии — 4565; последнее 08/07/2025 08:49
• после — 4649; последнее 08/07/2025 08:49
• просто — 4748; последнее 08/07/2025 08:49
• последний — 4454; последнее 08/07/2025 08:49
• как — 4747; последнее 08/07/2025 08:49
• который — 4514; последнее 08/07/2025 08:49
• о — 4745; последнее 08/07/2025 08:49
• the — 4757; последнее 08/07/2025 08:49
• торговля — 2083; последнее 08/07/2025 08:49
• эффект — 1653; последнее 08/07/2025 08:49
• президент — 3584; последнее 08/07/2025 08:49
• тарифы — 2665; последнее 08/07/2025 08:49
• io — 2480; последнее 08/07/2025 08:49
• расширяется — 95; последнее 08/07/2025 08:49
• пошлины — 639; последнее 08/07/2025 08:49
• полночь — 1772; последнее 08/07/2025 08:49
• ошеломляющий — 439; последнее 08/07/2025 08:49
• страны — 4866; последнее 08/07/2025 08:49
• взяли — 8866; последнее 08/07/2025 08:49
• начать — 2796; последнее 08/07/2025 08:49
• объявил — 3688; последнее 08/07/2025 08:49
• мужчина — 4577; последнее 08/07/2025 08:49
• снег — 958; последнее 08/07/2025 08:49
• анан — 76; последнее 08/07/2025 08:49
• снеговик — 202; последнее 08/07/2025 08:49
• развлечения — 3310; последнее 08/07/2025 08:49
• ich — 3267; последнее 08/07/2025 08:49
• die — 4390; последнее 08/07/2025 08:49
• mein — 2276; последнее 08/07/2025 08:49
• мастурбация — 712; последнее 08/07/2025 08:49
• sind — 5177; последнее 08/07/2025 08:49
• сила — 3583; последнее 08/07/2025 08:49
• сам — 2763; последнее 08/07/2025 08:49
• друзья — 3607; последнее 08/07/2025 08:49
• гигант — 1239; последнее 08/07/2025 08:49
• вместе — 3278; последнее 08/07/2025 08:49
• месяцы — 2845; последнее 08/07/2025 08:49
• вещи — 4425; последнее 08/07/2025 08:49
• смотреть — 4485; последнее 08/07/2025 08:49
• демократия — 2165; последнее 08/07/2025 08:49
• однажды — 3766; последнее 08/07/2025 08:49
• те — 4467; последнее 08/07/2025 08:49
• что-либо — 4208; последнее 08/07/2025 08:49
• делаю — 4378; последнее 08/07/2025 08:49

• Обсуждают сайт, который сканирует посты Bluesky и отмечает слова из словаря, которых ещё не встречал; часть ложных срабатываний связана с языком (французские посты, имена собственные вроде “Wheal”, названия групп типа “eluvium”).
• Некоторые удивлены, что среди “невиденных” попадаются вполне обычные английские слова, а также что сайт у некоторых показывает 0 из‑за блокировки скриптов или задержки загрузки.
• Автор сайта пояснил: бэкенд простой — SQLite с таблицами для статистики и слов; не ожидал популярности.
• Технически обсуждают использование Jetstream вместо «firehose», способы токенизации и структуры данных: хеш‑таблицы/множества, trie, оценка памяти ~25 МБ на 250–275k слов.
• Замечают, что проверено лишь ~4.9 млн постов (≈0.28% из 1.7 млрд), поэтому покрытие ограничено; метаданные о языке в Bluesky могут быть некорректны, что ухудшает точность.
• Есть опасения о пропускной способности и стоимости «firehose», но Jetstream считается достаточно легковесным; у части пользователей всё работает в Firefox без аккаунта.
• Появляются шутки и критика: кто‑то просто постит словарь, смешные “двойные находки”, замечания о дизайне, а также сомнения к другим проектам автора (ошибочная классификация “right‑leaning”).

Проект Hyperion исследует возможность пилотируемых межзвездных полетов на поколенческих кораблях с использованием нынешних и ближайших технологий. Такой корабль рассчитан на многовековой путь: экипаж живет и сменяется поколениями, поддерживая замкнутую экосистему с сельским хозяйством, жильем и системами жизнеобеспечения.

Инициатива i4is объявила победителей международного конкурса дизайна поколенческого корабля для 250‑летнего перелета к обитаемой планете. Междисциплинарные команды проектировали среду, способную поддерживать и развивать общество при жестких ресурсных ограничениях.

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

• Обитаемость для 1 000 ± 500 человек
• Искусственную гравитацию за счет вращения
• Достойные условия жизни и базовые потребности
• Надежные контуры жизнеобеспечения: пища, вода, отходы, атмосфера
• Механизмы передачи знаний и культуры

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

Благодарности жюри

Работы оценивали эксперты из архитектуры, инженерии и социальных наук (Университет Хьюстона; NASA‑JPL; Университет штата Аризона; Университет штата Орегон; Университет Южной Калифорнии).

1 место

Команда: Giacomo Infelise, Veronica Magli, Guido Sbrogio', Nevenka Martinello, Federica Chiara Serpe

Отзыв жюри

Chrysalis выделился системной целостностью и инновационной модульной архитектурой, глубокой проработкой (включая производство в космосе и подготовку экипажа в Антарктике). Модульная оболочка гибка и масштабируема; большой Купол придает выразительность. Сильны планирование строительства корабля и защита от радиации; конструктив реалистичен. Культурный блок можно развить, но концепт убедителен и зрелищен, отсылает к «Раме» и мировым кораблям 1980‑х.

2 место

Команда: Julia Biernacik, Jakub Kot, Aleksandra Wróbel, Jacek Janas, Michał Kucharski, Wiktoria Kuchta, Natalia Łakoma, Katarzyna Śliwa
Наставник: д-р хаб. Michał Kracik
Факультет промышленного дизайна (студия «Дизайн для экстремальных сред»), Академия изящных искусств в Кракове

Отзыв жюри

WFP Extreme отмечен за общий уровень и акцент на культуре и обществе: одежда, духовные пространства, «такси‑капсула», персонализированная униформа, защита от радиации. Системная целостность и интерьер при искусственной гравитации требуют доработки, но конструктив уместен для орбитальных применений. Балансирует технические амбиции с тонким видением будущей космической жизни.

• Обсуждение крутится вокруг концепции поколенческих звездолётов и конкурса дизайнов: многие впечатлены идеями и визуалами, но сомневаются в реализуемости.
• Критика охватывает социальные аспекты (учёт женщин, психическое здоровье, подростки на борту, эвтаназия как TBD), управляемость общества и этику многовекового эксперимента.
• Технические возражения: неверные расчёты скорости/времени, колоссальные энергетические и финансовые затраты, ненадёжность замкнутых экосистем (пример Biosphere 2), проблемы с воспроизводством без защиты магнитного поля.
• Обсуждают минимально жизнеспособную популяцию и варианты расширения генетического пула (замороженные эмбрионы), а также альтернативы: замороженные экипажи/эмбрионы, нанобот-/фон-Нейман‑зонды, рельсовые ускорители и орбитальные суперструктуры.
• Скептики ссылаются на художественные и научно-популярные примеры (KSR “Aurora”, “Aniara”, Хайнлайн) как иллюстрации «неизвестных неизвестных» и социальной деградации на пути.
• Есть и прагматики: «реальность» как единственный тест — не один «ковчег», а множество разных подходов; сначала нужно решить земные проблемы и освоить замкнутые биосистемы.
• Итоговый тон смешанный: от воодушевления образовательной ценностью и дизайном до убеждённости, что при нынешних технологиях поколенческие корабли — красивая, но несостоятельная фантазия.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.
• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.
• Вкус демо: простой файл

```
from litestar import Litestar, get

@get("/greet")
async def greet(name: str) -> str:
return f"Hi, {name}!"

app = Litestar([greet])
```
Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.
• Масштабирование кода, а не трафика:
• Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
• Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
• В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.

• В 70‑х некоторые системы (например, PDP‑10) имели 9‑битовые байты, но стандарт закрепился за 8 битами. Если бы байт был 9‑битным, ряд исторических случайностей сыграли бы нам на руку.
• IPv4: при 9‑битовых байтах адрес IPv4 был бы 36‑битным (~64 млрд адресов). Этого хватило бы до 2030‑х без массового NAT и тормозов с IPv6; позже проблему решили бы мягкими рыночными механизмами.
• UNIX time: 32‑битные метки ломаются в 2038, а 36‑битные прожили бы до 3058. Отрицательные охватывали бы времена с 882 года — достаточно для исторических нужд.
• Юникод: вместо 16‑битных 65 тыс. символов было бы 18‑битных 262 тыс. — хватило бы без болезненной унификации CJK; сейчас всех символов ~155 тыс. UTF‑9 стал бы скорее компрессией и уступил бы GZip; либо однобайтно‑двухбайтная схема при умеренной экономии на эмодзи.
• Указатели и память: 36‑битные ОС дали бы до 32 ГБ на процесс (вместо 2 ГБ у 32‑битных). Серверы всё равно виртуализируют; меньшие указатели экономят память и ускоряют код, хотя строки стали бы длиннее — общий баланс близок к нулю.
• Прочие выигрыши:
• 18‑битные AS‑номера не иссякли бы; порты/PID/UID просторнее.
• Кодирование инструкций x86/A64 чуть опрятнее; Thumb работал бы лучше.
• Полуточные 18‑битные числа прижились бы раньше; экзотика 4–5 бит не взлетела бы.
• Расширенный ASCII влез бы с греческим и стал бы «натовской» кодовой страницей; UTF‑9 привилегировал бы почти всю Западную Европу.
• Права Unix умещались бы в один байт (без «липких» битов). Оctal стал бы нормой вместо hex.
• 18‑битный цвет 6/6/6 даёт различия на грани восприятия; потеря альфа‑канала неприятна.

• Издержки? Существенных нет: адресация по битам не используется; деления на девять не требуется; размеры страниц/блоков ОС могли бы остаться прежними, ядру не пришлось бы менять основы работы.

• Обсуждение крутится вокруг гипотетического мира с 9-битными байтами: часть участников отмечает аппаратную неудобность непоказательных (не 2^n) размеров и сложность для мультипликаторов, адресации и сдвигов.
• Скептики считают аргументы «добавим по одному биту и всё станет лучше» натянутыми: решения о размерах всё равно принимались бы иначе, а выигрыш в 12.5% не компенсирует издержки и усложнение.
• Приводятся исторические примеры: PDP-8/10 с 12/36-битными словами, 6-битные коды, термин «octet» для однозначности; упоминается даже N64 с «внутренними» 9-битными байтами для GPU.
• По сетям: 36-битный IPv4 дал бы ~64 млрд адресов, но это лишь отсрочка дефицита; проблемы ASLR и безопасности 32-битной адресации 36 битами решаются слабо, переход на 64 бита всё равно был бы.
• Есть идеи альтернатив: 10-битные байты, тернарные системы, 9-й бит как признак продолжения для варинтов/инструкций, либо как служебный (ECC/контроль/метка данных).
• Отмечают экономику кремния: лишние провода/логика удорожают дизайн; если уже расширять шину, логичнее идти к степеням двойки (например, к 16 битам на «байт»).
• Итоговый тон дискуссии: 9 бит могли бы немного смягчить отдельные «почти-не-хватает» пороги (16/32-бит), но в целом это привнесло бы больше сложностей, чем пользы; ключ — лучше прогнозировать размеры, а не «маскировать» ошибки лишним битом.

MS used to have uservoice pages. They ignored issues, no matter how highly-voted they were. I once asked someone at MS about this, and they said they take their cues from other sources, like what industry partners ask them to fix at conferences.What a waste of time to have uservo

In my 20s I did a year long internship in Japan and lived in a dorm owned by the company I worked for.Single room with bed and desk, bathroom down the hall, shared cafeteria on the first floor with breakfast and dinner served every day (lunch expected to be eaten at the office).N

Моя предыдущая статья о обобщённых структурах данных в C готовила почву к теме: структура, которая заменяет динамические массивы, даёт стабильные указатели и хорошо работает с аренными аллокаторами. Её переоткрывали много раз под разными именами: “levelwise-allocated pile” (2001), в Zig — Segmented List, частично похожая на C++ std::deque. Мне нравится название Per Vognsen — Segment Array.

Скачать мой однофайловый заголовок segment_array.h можно, подписавшись на рассылку.

Идея проста: фиксированный массив указателей на сегменты; каждый следующий сегмент вдвое больше предыдущего; новые сегменты выделяются по мере необходимости. Поскольку элементы не двигаются, указатели на них стабильны, не остаются “дыры” в арене, а доступ по индексу — за O(1).

Реализация

Структура на C:

typedef struct {
u32 count;
int used_segments;
u8 *segments[26];
} SegmentArrayInternal;

Почему всего 26 сегментов? Из 64 бит указателя обычно реально используются 48, так что 49 сегментов уже перекрывают адресное пространство (~256 ТиБ). Я предпочитаю индекс u32 (до ~4 млрд элементов) — это даёт 32 сегмента. Ещё убираем 6 маленьких (1..32), начинаем с 64, остаётся 26 сегментов — хватает для 4 294 967 232 элементов (чуть меньше UINT32_MAX). Фиксированный массив рядом со структурой снижает риск промаха кэша.

Размеры сегментов — степени двойки: проще математика и быстрые сдвиги для индексов.

#define SMALLSEGMENTSTO_SKIP 6

#define log2i(X) ((u32) (8*sizeof(unsigned long long) \

• __builtin_clzll((X)) - 1))

u32 capacityforsegmentcount(int segmentcount) {
return ((1 << SMALLSEGMENTSTOSKIP) << segmentcount)

• (1 << SMALLSEGMENTSTO_SKIP);

}

void saget(SegmentArrayInternal sa, u32 index, sizet itemsize) {
int segment = log2i((index >> SMALLSEGMENTSTO_SKIP) + 1);
u32 slot = index - capacityforsegment_count(segment);
return sa->segments[segment] + item_size*slot;
}

log2i использует __builtin_clzll (подсчёт ведущих нулей) для быстрого вычисления номера сегмента.

Clang оптимизирует saget до ~10 инструкций x86-64 (-O3), так что узким местом будет память, а не вычисления индекса. При последовательной итерации можно обходить сегменты напрямую; в segment_array.h есть макрос.

Выделение нового элемента:

u32 slotsinsegment(int segment_index) {
return (1 << SMALLSEGMENTSTOSKIP) << segmentindex;
}

void saalloc(SegmentArrayInternal sa, sizet itemsize) {
if (sa->count >= capacityforsegmentcount(sa->usedsegments)) {
sizet segmentsize = itemsize * slotsinsegment(sa->usedsegments);
sa->segments[sa->usedsegments++] = malloc(segmentsize);
}
sa->count++;
return saget(sa, sa->count-1, item_size);
}

Замечание: можно сделать ёмкость строго степенью двойки, если первые два сегмента одинакового размера. Код станет менее изящным, но это спасает от ~50% потерь памяти при использовании как массива бакетов в хеш-таблице со степенью двойки.

Дженерики

Я применяю технику из прошлой статьи для типобезопасного хранения любого типа. Макрос связывает тип с общей структурой:

#define SegmentArray(type) \
union { \
SegmentArrayInternal internal; \
type *payload; \
}

Дальше макросы используют payload, чтобы передавать сведения о типе…

• Обсуждается структура «сегментированный массив» (экспоненциальные сегменты), её плюсы и минусы, и сравнение с существующими решениями: std::deque, ropes, Zig std.SegmentedList, rust-array-stump, plf::colony.
• Критика терминологии: это не «массив» в классическом смысле из‑за неконтигуозной памяти; многие API ожидают сплошной/страйдовый буфер и не подойдут.
• Производительность: при локальных L1-итерациях вычислительная часть индексации может быть ощутима; для больших объёмов память становится бутылочным горлышком. Предлагаются оптимизации итерации по сегментам и замечания про clz/bsr/lzcnt и опции компилятора.
• Виртуальная память как альтернатива: резервирование большого диапазона и по мере роста коммит страниц/guard pages; отмечены плюсы на Linux (MAP_POPULATE, mremap), но плохо для embedded/WASM.
• Сравнение с deque: фиксированные блоки vs экспоненциальные, поддержка prepend, рандом-доступ есть; реализация MSVC критикуется за малый размер блока, GNU/libc++ лучше.
• Недостатки сегментов: ухудшение предвыборки/кэш-локальности при линейной итерации, отсутствие стабильной непрерывности для API, сложность с хеш-таблицами при росте (rehash), потенциальный перерасход памяти при экспоненциальных размерах.
• Предложения: настраиваемый минимальный размер сегмента, функции «склейки» мелких сегментов, разбор условий, когда экспоненциальные сегменты оправданы, и замечания о чрезмерной макротрюковости в C/C23.

• Исправления
• Уточнено сообщение об ошибке с некорректной терминологией. (Louis Pilfold)
• JS: устранён сбой при использовании echo в модуле с функцией process. (Peter Saxton)
• Форматер: не переносит комментарий перед assert за него; корректно форматирует сообщения после echo/panic/todo/assert/let assert с комментарием перед ними; компилятор не генерирует неверный код для assert с пайпами на JS. (Giacomo Cavalieri)

• Форматирование битовых массивов
• Трейлинг-Запятая управляет разбиением: с запятой — много строк; без — в одну строку.
• Если несколько сегментов на строке и убрана завершающая запятая, форматер сохраняет сегменты по одному на строку. (Giacomo Cavalieri)

• Компилятор и генерация кода
• echo поддерживает пользовательское сообщение: echo 11 as "lucky number" печатает контекст и значение в stderr. (Giacomo Cavalieri)
• В сгенерированном JS doc-комментарии превращаются в JSDoc. (Giacomo Cavalieri)
• Уменьшен размер кода case на JS. (Surya Rose)
• Удаление неиспользуемого кода на этапе генерации (usage-based DCE). (Louis Pilfold)
• Улучшена поддержка echo для списков символов, ошибок и циклических ссылок JS. (Louis Pilfold)
• Улучшен внешний вид ошибок и предупреждений: контекстные метки выделяются иначе, чем источник проблемы. (Giacomo Cavalieri)
• Подсказка при импорте с точкой вместо слеша, с примерами корректного синтаксиса. (Zij-IT)
• Предупреждение при затенении импортированного имени верхнеуровневой константой/функцией. (Aayush Tripathi)
• Улучшено сообщение об неизвестной переменной, если, вероятно, имелась в виду проигнорированная (_x → x), с подсказкой. (Giacomo Cavalieri)
• Оптимизирован матчинг-паттернов на JS.

• Обсуждение посвящено релизу Gleam: многие хвалят дизайн языка, читаемость, статическую типизацию и паттерн-матчинг; приводят пример кода и делятся позитивным опытом использования в проектах.
• Есть ссылки на пост о версии 1.12.0 и доклад на YouTube; некоторые ждут дальнейшего созревания экосистемы и возможности шаринга кода между фронтендом и бэкендом.
• Критика: отсутствие интерфейсов/тайпклассов и оператора композиции; кому-то синтаксис и «Error -> Error» кажутся неэлегантными; snake_case непривычен после TypeScript.
• В ответ отмечают осознанную простоту языка и официальную позицию Gleam по отказу от тайпклассов.
• Существенная часть треда уходит в спор о «идеологичном» футере сайта (инклюзивность, антинацистская позиция, права транс-людей): часть считает это лишним, другие — важным для безопасности и качества сообщества.
• Подчеркивается, что Gleam — это не только язык, но и сообщество с явным кодексом поведения; отсутствие позиции тоже является позицией.
• Некоторые участники призывают вернуться к техническим темам релиза, чтобы не повторять одни и те же дискуссии.

Дэн Бертон, владелец Urban Trapping Wildlife Control в Салинасе, вскрыл дикого кабана и обнаружил «неоново‑синее, как черника» мясо. Он сообщил в округ Монтерей и Департамент рыбы и дичи Калифорнии (CDFW). Власти предупреждают охотников и трапперов: возможное загрязнение мясной ткани связано с поеданием животными антикоагулянтного родентицида дифацинола, широко применяемого в сельском хозяйстве против крыс, мышей и сусликов.

По данным CDFW, синий оттенок в мышцах и жире — повод не употреблять добычу (кабан, олень, медведь, гуси) и сразу сообщать о находке. Хищники и люди могут получить «вторичное воздействие», так как токсин сохраняется в органах и тканях отравленного животного. Обычно для токсической дозы требуется несколько кормлений, но возможны симптомы вроде вялости.

• Обсуждение касается диких свиней с неоново‑синей окраской мяса, что, как отмечают многие, связано с поеданием родентицидов, содержащих синий трифенилметановый краситель для идентификации яда.
• Пользователи подчеркивают риск вторичного отравления: яды поражают не только крыс, но и хищников, домашних животных и людей через пищевые цепочки; приводятся личные трагические примеры.
• Отмечена высокая разрушительность и инвазивность диких свиней для сельского хозяйства, их сверхбыстрая репродукция и потому активные меры по контролю численности (лов, отстрел и др.).
• Критикуют кликбейтные заголовки; предлагают более информативные формулировки и уточняют, что в Калифорнии уже ограничивают/запрещают некоторые яды из‑за воздействия на дикую природу.
• Дискуссия затрагивает альтернативы ядам (например, программы “community cats”) и важность предупреждать соседей при использовании отрав.
• Уточняют, что синее мясо обнаружили при отлове и эвтаназии свиней по заказу агрофирмы; обычно мясо могли бы пожертвовать, но в таких случаях это опасно.
• Некоторые участники делятся ссылками, замечаниями о слабом качестве репортажа и шутками, но общий вывод: причина синевы известна — краситель в родентицидных приманках и связанные с этим экологические риски.

• Логотип Multics
• Домой
• История »
• Возможности
• Мифы
• Project MAC
• Даты
• Глоссарий
• Проект истории
• Последний сайт
• Люди »
• Истории
• Фотографии
• Юмор
• Памятные вещи
• Библиотека »
• Статьи и доклады
• Технические статьи
• Документы разработки
• Исходники
• Симулятор
• Сайты »
• Хронология площадок
• AFDSC (Пентагон, Вашингтон)
• ASEA (Вестерос, Швеция)
• Avon (Бристоль, Англия)
• Bell Canada (2 площадки)
• CISL (Кембридж, Массачусетс)
• CNO (Миннеаполис, Миннесота)
• DND-H (Галифакс, Канада)
• DOCKMASTER (АНБ, Мэриленд)
• FORD (Детройт, Мичиган)
• GM (Детройт, Мичиган)
• Майнц (Германия)
• MIT (Кембридж, Массачусетс)
• NWGS (ВМС США, 4 площадки)
• OU (Рочестер, Мичиган)
• PRHA (Сан-Хуан, Пуэрто-Рико)
• RADC (Рим, Нью-Йорк)
• RAE (Фарнборо, Англия)
• STC (Лондон, Англия)
• System-M (Финикс, Аризона)
• Systeme X (Лувесьен, Франция)
• UC/ACTC (Калгари, Канада)
• USGS (3 площадки)
• USL (Лафайет, Луизиана)
• VPI (Блэксберг, Вирджиния)
• О сайте »
• Изменения
• Новости
• Ссылки
• Галерея
• Карта сайта

• Поиск
• Меню: История: Возможности | Мифы | Project MAC | Даты

• Участники обсуждают влияние Multics на современную вычислительную технику: от безопасности и архитектуры до наследия в текущих проектах (например, STOP, происходящий от SCOMP/STOP).
• Делятся воспоминаниями об использовании Multics в британских университетах в 80-х: система считалась быстрой, апгрейды памяти были ощутимыми, доступ через терминалы и JANET, позитивный опыт работы.
• Мнения расходятся: одни критикуют «всеобъемлющесть» дизайна и сложность (в контраст к UNIX), другие подчёркивают сильные стороны Multics — кольца защиты, строгие политики доступа (MAC/ACL), сегментную память и отсутствие переполнений буфера.
• Отмечают ограниченную портируемость Multics к немногим мэйнфреймам, несмотря на теоретическую переносимость.
• Ссылаются на полезные ресурсы: мифы о Multics, оценка безопасности B2, страницы по безопасности данных (AIM/MAC), «Три вопроса» для анализа багов, меморабилии, хронологии и список недавних изменений.
• Обсуждают спад активности оригинальных установок (последние закрытия около 2000 г.), эмулятор DPS8M и печальные новости об уходе участников проекта.
• Несколько комментаторов переосмыслили роль UNIX после знакомства с историей Multics и более ранними идеями (Xerox PARC), видя в Multics самостоятельную и богатую идеями систему, а не только «предтечу UNIX».

Far better to promote device controls than service ID checks. It allows parents to decide what age to allow kiddo to see certain content, not the state. It allows others to restrict content too. E.g. a gambling addict who doesn't want to see gambling content.* It has no risk of

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

Jules интегрируется с инструментами разработчиков, может брать на себя длинные задачи, делить их на шаги, сообщать о прогрессе и запрашивать уточнения только при необходимости. Доступен через Google Labs и ориентирован на повышение продуктивности как отдельных инженеров, так и команд, позволяя запускать больше экспериментальных веток и быстрее проводить ревью.

• Пользователи жалуются на запутанные подписки Google: разные продукты (Jules, Gemini App/CLI, Code Assist) разбросаны между Workspace и GCP, цены и доступ скрыты или требуют согласий и биллинга.
• Опыт с Jules противоречивый: часть считает его слабее Claude Code, Copilot/Claude Sonnet и Gemini CLI (низкое качество кода, проблемы в монорепо, зацикливание, отсутствие кнопки STOP, баги UI), другие довольны асинхронным форматом и считают удобным для пачек задач, тестов и сайд‑проектов.
• Замечены регрессии: лимит задач на бесплатном плане снизили с 60 до 15; качество, по словам некоторых, упало после увеличения дневных лимитов на раннем превью.
• Пользователи хотят интеграции с GitHub (issues, комментирование PR для фидбэка), явного просмотра публичных улучшений кода и лучшей связности с Gemini CLI/Actions.
• Есть путаница в позиционировании: что такое «асинхронный кодовый агент», чем Jules отличается от Gemini CLI и с кем он конкурирует (Claude Code, Codex, Crush).
• Критика брендинга/UX: «детский» лендинг, слабый контраст, плохой пиксель‑арт; общее ощущение, что UI отстает от возможностей модели.
• Итоговое восприятие: интерес к формату асинхронных агентов есть, но текущая реализация Jules часто уступает Claude Code по скорости/качеству и стабильности; пользователи просят прозрачные тарифы и единый продуктовый опыт.

Это вторая часть серии о разработке Tyr — современного GPU‑драйвера на Rust для ядра Linux с поддержкой Arm Mali на CSF.

Разберем, как работают GPU‑драйверы, на примере VkCube — простого приложения на Vulkan, рисующего вращающийся куб. Простота сцены помогает понять путь данных и команд от приложения к GPU.

UMD и KMD

• UMD (usermode) реализует API вроде Vulkan/OpenGL/OpenCL и преобразует команды приложений в низкоуровневые команды для GPU. В нашем случае это panvk из Mesa.
• KMD (kernel mode) соединяет UMD с железом: инициализирует устройство, управляет памятью, очередями, планированием и уведомлениями. В нашем случае это Tyr, нацеленный попасть в основное дерево Linux.

Что делает UMD

• Подготавливает данные: геометрию, текстуры, машинный код шейдеров, матрицы трансформаций.
• Просит KMD разместить их в памяти GPU, создает VkCommandBuffer с командами отрисовки, настраивает состояние конвейера, указывает, куда писать результат, и как получать сигнал о завершении.

Про шейдеры

• Это полноценные программы на GPU. Для VkCube им нужны хотя бы геометрия, цвета и матрица вращения, чтобы расположить и раскрасить куб и крутить его.

Что делает KMD

• Выделяет и отображает память, изолируя процессы в отдельных контекстах/VM.
• Принимает работу от UMD, ставит в аппаратные очереди, отслеживает зависимости и завершение.
• Планирует выполнение на массово параллельном, асинхронном железе, соблюдая порядок и справедливое распределение ресурса между клиентами.
• Инициализирует устройство: тактирование, питание, стартовые процедуры; обеспечивает совместный и честный доступ приложений к GPU.

Ключевой вывод

• Основная сложность — в UMD, который переводит высокоуровневые API в команды GPU. Но KMD обязан предоставить надежные примитивы: память, очереди, синхронизацию, планирование и разделение ресурсов, чтобы UMD было реально реализовать.

Интерфейс драйвера

• На основе этих задач KMD экспонирует минимальный набор операций: запрос сведений об устройстве, создание/уничтожение VM, привязка/отвязка памяти к VM, получение состояния VM, отправка работ в очереди и механизмы уведомлений — тот же API, что у C‑драйвера Panthor для того же железа.

• Обсуждение статьи о драйвере GPU: часть читателей хвалит материал, но считает его слишком коротким и ждёт продолжения/второй части.
• Уточняют, что речь идёт о драйвере panthor для Mali CSF (на RK3588), а не panfrost; один из комментаторов отмечал баги в Firefox на RK3588, ему ответили про соответствующий драйвер.
• Спор о фокусе: одни подчёркивают важность того, что это один из первых GPU-драйверов Linux на Rust; другие критикуют кликбейт заголовок и считают, что нужно акцентировать Mali CSF, а не Rust.
• Техническая дискуссия: вопрос о целесообразности uring_cmd вместо ioctl; ответы поясняют, что из-за природы асинхронных очередей GPU дополнительная CPU-очередь мало что даст, а интерфейс драйвера следует ожиданиям Mesa.
• Отмечают, что текущая часть охватывает в основном границу пользователь/ядро и управление очередями/буферами; «основное действие» — выполнение команд GPU — ожидается в следующих частях.
• Дополнительно подчёркивают сложность современных GPU-драйверов и их объём в ядре Linux, что оправдывает выбранные подходы и терминологию.

• За 3 месяца мы масштабировали «мышление» Qwen3-4B: выше качество и глубина рассуждений. Представляем Qwen3-4B-Thinking-2507:
• Существенно лучше на задачах логики, математики, науки, кода и академических бенчмарках.
• Улучшены общие навыки: следование инструкциям, инструменты, генерация текста, согласование с предпочтениями.
• Расширено понимание длинного контекста: 256K.
• Версия с увеличенной длиной «мышления» — рекомендуем для сложных задач.

• Обзор модели:
• Тип: Causal LM; Этапы: пре-/посттренировка.
• Параметры: 4.0B (без эмбеддингов 3.6B); Слоёв: 36; GQA: 32 Q / 8 KV.
• Контекст: 262 144 токенов.
• Поддерживается только режим «thinking»; enable_thinking=True не нужен. Шаблон чата добавляет <think> автоматически; нормален вывод, содержащий только </think>.
• Подробности: блог, GitHub, документация.

• Производительность (избранное):
• Знания: MMLU-Pro 74.0; MMLU-Redux 86.1; GPQA 65.8.
• Рассуждения: AIME25 81.3; HMMT25 55.5; LiveBench 71.8.
• Код: LiveCodeBench v6 55.2; CFEval 1852; OJBench 17.9.
• Алайнмент: IFEval 87.4; Arena-Hard v2 34.9; WritingBench 83.3.
• Агенты: BFCL-v3 71.2; TAU1/2 — лучшие в ряде доменов.
• Мультиязычность: MultiIF 77.3; PolyMATH 46.2.
• Примечания: выигрыш на Arena — GPT-4.1; для сложных задач — вывод до 81 920 токенов, иначе 32 768.

• Быстрый старт:
• Нужен свежий transformers (иначе KeyError: 'qwen3').
• Пример кода: загрузить AutoTokenizer/AutoModelForCausalLM, применить chat template, сгенерировать до 32 768 новых токенов, выделить «thinking»-часть до токена </think> (ID 151668) и основное содержимое.
• Для продакшна: sglang>=0.4.6.post1 или vllm>=0.8.5; можно поднять OpenAI-совместимый сервис.

• Обсуждают малый открытый модель Qwen3-4B (в т.ч. «Thinking/Instr»), её доступность в LM Studio и на Hugging Face, возможность запуска на ПК, Mac (mlx 4–8 бит) и даже на слабом железе; полный контекст 262k токенов может требовать десятки ГБ RAM.
• По отзывам: модель быстрая, компактная и по многим бенчмаркам заметно улучшена; в ряде метрик приближается к старой 30B MoE-версии при ~7,5× меньшем размере, но новая 30B-A3B всё же сильнее.
• Практический опыт: хороша в анализе задач, но встречаются галлюцинации в предложениях/советах.
• Идёт сравнение с Gemma 3n: на общих тестах (напр. AIME, LiveCodeBench) Qwen3-4B-Thinking показывает значительно более высокие результаты.
• Обсуждают надёжность метрик: многие бенчмарки оцениваются GPT‑4.1; возникают вопросы о возможной адаптации моделей под «угодные» ответы и нехватке ручного аудита.
• Для «народных» оценок советуют LM Arena, Artificial Analysis, OpenRouter stats и r/LocalLlama, но подчёркивают ограниченную надёжность толпы.
• Вопросы пользователей: как соотносится контекст и RAM; варианты для iPhone/Apple Silicon; ссылки на готовые gguf и mlx-сборки предоставлены.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости:
"libpupa": "1.2.3"
Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это:
"liblupa": "0.7.8"
То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.

Введение

Я часто использую отладчик, но привык и к выводной отладке, особенно в юнит-тестах. Хотелось улучшить её и чаще подключать отладчик.

Улучшение выводной отладки

Главная проблема — «шум»: в цикле интересна одна итерация, а печатается всё. Или удобнее читать форматированную структуру, но приходится раскидывать print’ы по коду. В Zig тесты используют error’ы, значит можно печатать только при падении теста через errdefer:

test {
errdefer std.debug.print("{f}", .{ast});
// ...
}

Так контекст появляется только при ошибке, без засорения лога.

Запуск тестов в отладчике

Просто запустить seergdb или gdb -tui неудобно: тестовые бинарники лежат в zig-cache. Трюк из ziggит: build.zig может запускать команды и передавать путь артефакта:

// seergdb — GUI фронтенд для gdb
const debugger = b.addSystemCommand(&.{ "seergdb", "--run", "--" });
debugger.addArtifactArg(exeunittests);

const debug_step = b.step("debug", "Run unit tests under debugger");
debug_step.dependOn(&debugger.step);

Это запускает правильный бинарник. Но отладчик сработает лишь на брейкпоинте или панике, тогда как раннер тестов «проглатывает» ошибки.

Комбинация трюков

Добавим @breakpoint через errdefer:

test {
errdefer @breakpoint();
}

Так мы попадаем в точку ошибки, видим контекст и вывод std.testing.expect*. Минус: при zig build test отчёт показывает падение всего шага тестов, а не отдельных кейсов. Нужна возможность включать брейкпоинты выборочно.

Условная компиляция

Через build options пробрасываем флаг, решающий, вызывать ли @breakpoint в тестах.

Минимальный скрипт сборки, запускающий тесты, дополняем опциями:

const std = @import("std");

pub fn build(b: *std.Build) void {
const target = b.standardTargetOptions(.{});
const optimize = b.standardOptimizeOption(.{});

const lib = b.addModule("zig-test-patterns", .{
.rootsourcefile = b.path("src/root.zig"),
.target = target,
.optimize = optimize,
});

const options = b.addOptions();
options.addOption(bool, "debugger", false);
lib.addImport("config", options.createModule());

const modtests = b.addTest(.{ .rootmodule = lib });
const runmodtests = b.addRunArtifact(mod_tests);

const test_step = b.step("test", "Run tests");
teststep.dependOn(&runmod_tests.step);
}

В коде тестов:

const std = @import("std");
const config = @import("config");

test "errdefer @breakpoint()" {
errdefer if (config.debugger) @breakpoint();
return error.FixMe;
}

test "no breakpoint" {
return error.FixMe;
}

zig build test — без брейкпоинтов. Но менять значение флага так — значит пересобирать build.zig. Добавим опцию прямо в систему сборки:

var options = b.addOptions();
const use_debugger = b.option(
bool,
"debugger",
"Enables code intended to only run under a debugger",
) orelse false;
options.addOption(bool, "debugger", use_debugger);

Теперь можно переключать поведением командой:

zig build -Ddebugger test

И, при желании, привязать шаг запуска отладчика к этому флагу.

• Участники хвалят согласованность базовых конструкций Zig: минимализм синтаксиса и мощь comptime позволяют элегантные решения без излишней сложности.
• Особый интерес вызвал errdefer: многие отмечают, что это упрощает тесты и отладку; звучит мнение, что такую возможность «стоит иметь каждому языку».
• Обсуждают практики отладки: полезны советы по интеграции дебаггера в build.zig, что избавляет от ручного поиска исполняемого файла в кэше.
• Поднимается вопрос об ошибках без полезной нагрузки в Zig: при парсинге (например, JSON) типовые ошибки вроде UnexpectedToken недостаточно информативны; интересуются паттернами передачи дополнительного контекста.
• Есть замечание о смешении стилей именования (camelCase в stdlib vs snake_case у автора), что может сбивать с толку.
• Отмечают эстетику сайта и блога: шрифты (Berkeley Mono), цветовую схему и ретро-оформление — «как в старых DOS-играх».
• Проводится параллель с D: аналогичная идея реализована через scope(failure), что подчеркивает общность концепции.

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

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

Команда исследователей предложила новый алгоритм, который обходится без сортировки и работает быстрее всех «сортирующих» методов, преодолев сорокалетний барьер. Роберт Тарьян назвал результат поразительным.

Графы описывают вершины и ребра с весами (длина, время и т.п.). Задача: по данному источнику найти кратчайшие пути до всех вершин. Алгоритм Дейкстры (1956) идет «волной» наружу: зная оптимальные пути к ближайшим, находит пути к дальним. Но конечный результат — упорядоченный набор кратчайших расстояний, и потому скорость ограничена сортировкой. В 1984 году Тарьян с соавтором улучшили Дейкстру до этого предела: чтобы ускориться дальше, нужно избегать сортировки.

В конце 1990-х — начале 2000-х Торуп и другие обошли барьер для частных случаев, вводя ограничения на веса. Обобщить техники на произвольные веса не удавалось, и прогресс застопорился. Ран Дуань не согласился с пессимизмом и стремился сломать барьер для всех графов — и прошлой осенью добился цели.

Идея Дуани (созревшая к 2021 году): вместо того чтобы на каждом шаге сканировать всю «границу» уже исследованной области, как делает Дейкстра (что со временем замедляет ход), группировать соседние граничные вершины в кластеры и рассматривать по одному представителю из каждого. Это уменьшает число кандидатов и может вести не к ближайшей вершине — значит, зависимость от сортировки исчезает. Главная трудность — доказать, что кластеризация действительно ускоряет процесс на каждом шаге и в сумме.

За следующий год Дуань проработал идею и к осени 2022-го был уверен, что технические барьеры преодолимы.

• Обсуждение вокруг нового алгоритма SSSP с детерминированной сложностью O(m log^(2/3) n), который улучшает Дейкстру на разреженных графах; ссылку дали на arXiv: 2504.17033.
• Участники отмечают, что выигрыш зависит от структуры графа: для дорожных сетей обычно m ≈ c·n (c ~ 4–6 для ориентированных), что даёт O(n log^(2/3) n); для очень плотных графов (m ~ n^2) преимущество может исчезать.
• Возникают вопросы о сравнении логарифмических степеней, применимости к задачам вроде TSP с почти полными графами, и сохранении гарантии глобального минимума как у Дейкстры.
• Некоторые считают алгоритм сложнее Дейкстры, но отмечают теоретическую значимость прорыва и отсутствие «фancy math», что делает результат удивительным.
• Обсуждают возможные гибриды с рандомизацией и практическое влияние на реальные графы (улицы, геймдев).
• Есть скепсис о «позднем открытии» и комментарии про то, что практики могли бы дойти до подобных идей, но не оформляют их академически.
• Вспоминают вклад классиков (Тарjan и др.) и проводят аналогию с TimSort: практичная оптимизация поверх классики.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

OK, so every agentic prompt injection concern and/or data access concern basically immediately becomes worst case scenario with this, right? There is now some sort of "official AI tool" that you as a Federal employee can use, and thus like any official tool, you assume it's prope

• Обсуждение о том, что один из корпоративных Salesforce-инстансов Google был скомпрометирован через вишинг-атаки (UNC6040), с кратковременной утечкой контактных данных и заметок по малому и среднему бизнесу; официальный тон смягчает масштаб, что вызывает скепсис.
• Комментаторы сомневаются в формулировках “лишь базовые и публичные данные”, предполагая, что ценность для злоумышленников была реальной (возможны вторичные схемы, например мошенничество с биллингом).
• Многих удивляет, что Google использует Salesforce; объяснения: историческое наследие, быстрые поглощения, а также предпочтения команд продаж и маркетинга к индустриальным стандартам вместо внутренних инструментов.
• Приводятся истории о неудачных внутренних CRM у Google: баги, нехватка функций, нежелание инженеров поддерживать; продажи и PM часто продавливают Jira/Salesforce ради скорости найма и онбординга.
• Отмечается культурный сдвиг: замена внутренних решений “джанковыми” шаблонными процессами Salesforce; внутренние инструменты больше для инжиниринга.
• Уточнения: у Google десятки тысяч сотрудников в продажах/маркетинге; часть саппорт-систем GCP ранее зависела от Salesforce; выбор строить/покупать/партнериться по CRM оценивался и часто оказывался экономически нецелесообразным для собственной разработки.
• Общий вывод: инцидент — результат классической социальной инженерии, а не технического взлома; реакция компании стремится минимизировать восприятие ущерба, вызывая дискуссии о прозрачности и рисках использования сторонних SaaS.

If you're looking for a fantastic dev-focused linux distro, I can't say enough good things about Bluefin Linuxhttps://projectbluefin.io/ I really appreciate that he included a video with great narration. So much better than the animated gifs that provide too little context and go

Claude Code IDE для Emacs

Обзор

• Интеграция с Claude Code CLI через MCP создает двусторонний мост между Claude и Emacs.
• Claude получает доступ к возможностям Emacs: LSP, проекты, Elisp-функции, что делает его «понимающим Emacs» помощником в вашем рабочем процессе.

Возможности

• Автоопределение проекта и управление сессиями
• Терминал с цветом (vterm/eat)
• Реализация MCP для IDE-интеграции
• Инструменты для файлов, состояния редактора и рабочего пространства
• Расширяемый сервер MCP для Emacs-команд (xref, tree-sitter, project и др.)
• Диагностики Flycheck/Flymake
• Расширенный дифф с ediff
• Поддержка tab-bar и отслеживание выделений/буферов

Интеграция инструментов Emacs

• LSP через xref (eglot, lsp-mode) для навигации по коду
• Tree-sitter для анализа AST
• Imenu для структуры символов
• Project для операций на уровне проекта
• Любую команду/функцию Emacs можно выставить как MCP-инструмент: поиск и рефакторинг по проекту, доступ к режимам, выполнение кастомного Elisp.

Скриншоты

• Осведомленность об активном файле — знает, какой файл открыт
• Контекст выделения — работает с выделенным текстом
• Продвинутый дифф с диагностикой — ediff и доступ к ошибкам/предупреждениям
• Автоматические упоминания текста — вставка ссылок на выделение в диалог
• Восстановление сессии — продолжение разговоров с флагом –resume

Установка
Предварительные требования

• Emacs 28.1 или новее

• AI-инструменты вроде Claude Code облегчают жизнь нишевым редакторам: вместо IDE-фич они просто подключаются к агенту и концентрируются на своих сильных сторонах.
• Emacs/Vim выигрывают благодаря открытости и elisp: агент может читать/менять состояние редактора и быстро адаптироваться.
• Уже есть несколько интеграций (claude-code.el, eca, claudemacs, claude-code-emacs), но UX в терминальных обёртках пока неидеален.
• Пользователи просят локальных моделей, Org-mode-интеграции, поддержки OpenCode и безопасной работы с чувствительными файлами.
• Часть сообщества опасается «утечки» конфиденциальных данных в облако и жалуется на сложность конфигурации.

This pops up every few years, and I bet once it gets in it never goes away. It seems asymmetric that one side only has to win once to win permanently while the other side has to win constantly. Is there any mechanism to stop this in the EU and make this kind of legislation explic

303Gen

• Обсуждение посвящено веб-инструменту в стиле TB-303: пользователи хвалят звук, музыкальность и авто-генерацию совместимых полиритмов для баса, лида и дрона, отмечают ностальгию по ReBirth и 90-м.
• Автор сообщает, что проект старый и незавершённый; добавил полифилл для cancelAndHoldAtTime в Firefox и выделил часть таймкипинга в библиотеку beatstepper.
• Многие просят открытый исходный код, локальный запуск, экспорт MIDI/стемов, визуализацию паттернов (пиано-ролл), сохранение/загрузку, MIDI синхронизацию и транспорт, а также продолжение воспроизведения при Regenerate.
• Есть баг-репорты: не работало в Firefox до полифилла, в Chromium после Stop остаётся тихий хвост/эхо, иногда нужно жать Stop несколько раз.
• Пользователи делятся альтернативами и вдохновляющими ссылками: Endless Acid Banger, roland50.studio, музыка Vitling, ивенты Acid August.
• Инструмент вызывает желание вернуться к электронной музыке; звучание напоминает Frank Klepacki/Red Alert 2, Dynamix на C64; просят добавить 909-кит.
• Автор кратко описал генерацию: ноты из выбранной гаммы/октавы, деление паттерна на чанки с вероятностным копированием/обновлением и настройкой повторов; сообщество хочет статью о методе.

I’ve used the reverse. When making a new module I’ve let the llm make up an api and I’ve used the names suggested as inspiration of what might come natural to others, to make the use more intuitive. > LLMs hallucinated a package named "huggingface-cli" [...] it is not the name of

I checked out the Wired article. Not recommended seems to mostly be about the fact that it's a tiny display, which some people (like the reporter) will have trouble to read. That the screen degraded didn't help of course. The reporter doesn't want to use a web dashboard to check

• Самая быстрая и надежная open-source платформа для трейдинга. Торгуйте любым классом активов в одном месте. Событийные бэктесты на любых исторических данных. Лайв-трейдинг без изменений кода.
• Решения:
• Open Source — репозиторий на GitHub.
• Cloud Platform — облачная платформа Nautilus Cloud.

• Компания: О нас, Команда, Партнеры, Правовое.
• Ресурсы: Документация, Образование (скоро), Блог, Начать, Discord.
• Платформа для алгоритмической торговли:
• Интеграция данных: загрузка кастомных/сырых данных в формат parquet.
• Построение стратегий: Python API, стрим до 5 млн строк/с, больше RAM.
• Аналитика: моделирование рынка с наносекундной точностью, событийные результаты.
• Быстрая итерация: экстремально быстрые бэктесты.
• Лайв-торговля: надежный запуск, паритет кода бэктест/лайв.
• Исполнение: высокопроизводительное low-latency исполнение на Rust.

• Классы активов:
• Крипто: спот, фьючерсы, деривативы, опционы; нормализованные инструменты.
• Фьючерсы: активация/экспирация, базовые активы, биржи, лоты, множители.
• Акции: шорт-ограничения, кэш/маржин, круглые/нестандартные лоты, мульти-биржа.
• Опционы: Греки и сигналы на внутренней шине; точные спецификации контрактов.
• FX: спот и деривативы, базовая/котировая/расчетная валюты; биржи и ECN.
• Беттинг: спортивные и альтернативные рынки, полный стакан, адаптер Betfair.

• Безлимитные бэктесты стратегий, площадок и рынков. Стратегии для любых инструментов и веню.
• Ключевые возможности:
• Простые модульные компоненты: Clock, Cache, MessageBus, Portfolio, Actors.
• Точное время: наносекундные часы для бэктеста и лайва.
• Быстрая конфигурация: торговля на множестве веню и параметров без изменения кода стратегии.
• Продвинутые ордера: post-only, reduce-only, OCO, OTO и др.
• Интеграции API: быстрый коннект новых бирж и провайдеров данных.
• Высокая производительность: ядро на Rust.

• Партнеры: Databento, OKX.
• Выразите идеи стратегий через чистый, мощный API:
• Python API: совместим с ML/AI-фреймворками и любым Python-кодом.
• Любые типы стратегий: настраиваемые компоненты для любой идеи.
• Конфигурации стратегий: упрощение настройки.

• Обсуждение крутится вокруг алгоритмической торговли и платформ, с акцентом на рисках и иллюзии «успешных» стратегий: многие отмечают, что без информационного или инфраструктурного преимущества (HFT) торговля похожа на подбрасывание монетки.
• Несколько комментаторов поделились опытом: высокие проценты «успешных» сделок с редкими, но разрушительными просадками; out-of-sample провалы ML/бэктестов; необходимость чёткой «edge» (ребейты, латентность, маркет-мейкинг, арбитраж).
• Выделяют, что разработка OMS/интеграций и бэктестера — «лёгкая часть»; основная сложность — поиск и валидация стратегий и управление рисками (упоминание негативной асимметрии, LTCM, Карвер).
• Практический совет многим — предпочесть долгосрочное инвестирование (индексные фонды, buy-and-hold) вместо активного трейдинга; ряд участников подтвердили, что это повысило их результаты и снизило стресс.
• Обсуждается платформа Nautilus: впечатляющая полнота (особенно risk engine), но интеграция с брокерами (IBKR и др.) и регуляторные проверки сложны; указывается на список интеграций и сравнение с LEAN/QuantConnect.
• Скепсис к розничной алготорговле: необходимость капитала/инфраструктуры, риск банов у брокеров, низкомаржинальные «нейтральные» портфели в HFT требуют больших ресурсов; многие считают, что в одиночку стабильно зарабатывать почти нереально.
• Встречаются идеи обучающих симуляторов и простых целей (например, $1/день как POC), но общий тон — трезвый: дисциплина риск-менеджмента важнее «волшебных» моделей, а охота за стратегиями — глубокая и дорогостоящая нора.

• Недавние записи

Архив блога

• Одно из ключевых достижений вычислений — сжатие данных: мы уменьшаем размер, сохраняя всю информацию (без потерь), передаём и восстанавливаем исходник.
• Раньше сжатие было необходимо: носители малы, сети медленны. Сейчас это не всегда критично, но по‑прежнему полезно: эта страница почти наверняка пришла к вам в сжатом виде, что ускоряет загрузку и снижает нагрузку на сервер.
• Забавно, что в 2025 мы нередко делаем противоположное. Пример: Бобу нужен новый рабочий компьютер. Его просят написать 4 абзаца обоснования. Он просит LLM сгенерировать текст и отправляет менеджеру.
• Менеджер получает длинное письмо, копирует его в LLM и просит резюме в одном предложении: «Нужен новый компьютер, старый медленный и мешает продуктивности». Заявку одобряют.
• Я называю это «инфляцией LLM»: легко превращать короткое и простое в длинное и видимо глубокое — и обратно, длинное и «глубокое» в короткое и простое.
• Это не упрёк LLM. Но стоит задуматься, почему мы раздуваем контент: в лучшем случае поощряем туманность и трату времени; в худшем — скрываем отсутствие ясной мысли. LLM лишь обнажают масштаб. Возможно, это подтолкнёт нас к изменениям!
• 2025‑08‑06 10:50 — Более раннее
• Обновления: Mastodon, Twitter, RSS, e‑mail
• Сноски:

И, разумеется, теория информации, но здесь важны практические эффекты.

• Комментарии

• Обсуждение вращается вокруг “инфляции текста” из‑за LLM: люди генерируют лишнюю прозу для бюрократических требований, а получатели затем используют LLM для сжатия обратно до сути.
• Многие считают проблему культурной и организационной: длинные форматы служили фильтром/сигналом усилий и «критического мышления», но с LLM этот сигнал обесценился.
• Часть участников утверждает, что инфляция текста существовала и раньше; LLM лишь ускорили процесс и обнажили масштаб пустых формальностей.
• Другие видят в этом шанс: нормализовать краткость, требовать брифы/буллеты, а при необходимости поручать LLM расширение текста на стороне читателя.
• Встречаются скепсис и критика вымышленных кейсов (например, про “4 абзаца” для покупки ПК) как нереалистичных или оправдывающих бюрократию.
• Предлагаются альтернативные метрики и взгляды: оценивать модели по способности к компрессии информации; замечается, что «формальная вежливость» и сигналы статуса в языке подпитывают многословие.
• Общий вывод: инструменты генерации/суммаризации меняют баланс доверия и сигналов в коммуникации; организациям стоит переосмыслить процессы и поощрять ясность и краткость.

• Обсуждение: «About the BLOBs in Ventoy · Issue #3224 · ventoy/Ventoy».
• Страница GitHub Issues перегружена навигацией и служебными блоками (меню, поиск, вход/регистрация, продукты/решения GitHub, сохранённые запросы, уведомления о сессии и т.п.).
• Содержательная часть самого обсуждения по теме BLOBов в Ventoy в предоставленном фрагменте отсутствует: видны только заголовки разделов GitHub, элементы интерфейса и ссылки.
• Вывод: по данному отрывку невозможно извлечь детали о BLOBах в Ventoy (описание проблемы, позиции участников, решения или выводы). Чтобы перевести и сократить по сути, нужен текст самих сообщений Issue.

• Обсуждение вокруг доверия к Ventoy: часть участников не доверяет проекту из‑за рисков компрометации цепочки поставок и неоднозначной позиции мейнтейнера по “блобам”; другие продолжают пользоваться из‑за удобства.
• Некоторые сообщают о многолетних нерешённых вопросах безопасности и подозрениях к iVentoy (упоминание обходов сертификации на Windows), запрашивают ссылки и уточнения.
• Практический опыт разделился: у одних Ventoy “просто работает”, в т.ч. с Arch и Windows; у других встречались проблемы с Arch или путаница в установщиках из‑за EFI/ISO, приходилось возвращаться к “одиночным” флешкам.
• Звучит альтернатива Ventoy: сетевой бут (PXE) с набором инсталляторов и утилит, а также USB‑корпуса, эмулирующие DVD, как способ уйти от несовместимостей.
• Пользователи ценят ключевые фичи Ventoy: мульти‑ISO на одной флешке и возможность хранить обычные файлы параллельно.
• Новички в теме просят источники по “драме” и объяснения; часть скептиков не готова доверять Ventoy до появления прозрачной сборки без закрытых бинарников.
• В стороне идёт языковая ветка: уточнение, что “blob” исторически не акроним, хотя в базах данных закрепилось “Binary Large Object”; обмен шутками и ссылками.

Everybody is talking about Chrome, but I tell ya what I have that disabled on my Android in favor of Firefox. Firefox on mobile with full-fat uBlock Origin is the closest thing to parity with desktop web access you can get.I don't just block ads, I block elements on sites I don't

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

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

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world')) # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.

• Сгенерированное ИИ изображение, где ИИ руками «отвергает» меня. Очень мета.

В октябре 2024 Anthropic представила «Claude Computer Use», позволяющую ИИ управлять компьютером, копировать данные из браузера в таблицы и т.п. Я поддерживаю библиотеку для управления компьютером и этой весной решил разобраться, как они это делают. К моему удивлению, Anthropic использует мою библиотеку enigo.

Проверить использование enigo в Claude Desktop для macOS можно так:

• 7z x Claude.dmg
• perl -nle 'print $& while /.{0,67}enigo.{0,30}/g' Claude/Claude.app/Contents/Resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node

Вывод содержит путь к enigo-0.2.1/src/macos/macos_impl.rs

На Windows:

• 7z x Claude-Setup-x64.exe
• 7z x AnthropicClaude-0.11.6-full.nupkg
• perl -nle 'print $& while /.{0,75}enigo.{0,26}/g' Claude-Setup-x64/AnthropicClaude-0.11.6-full/lib/net45/resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node

Вывод указывает на enigo-0.2.1/src/win/win_impl.rs

Я горжусь, что enigo дорос до продакшена у компании с огромным бюджетом. Эмуляция ввода сложна из‑за слабой документации и платформенных особенностей. На мой взгляд, enigo — отличный выбор: работает на Windows, macOS, *BSD и Linux (Wayland, X11, libei) без root; написан на Rust (безопасность памяти, высокая скорость); самый популярный на crates.io (~300k загрузок, 1200+ звёзд). И всё же тревожно, что мой хобби‑проект установлен на тысячах устройств.

Сколько я на этом заработал? Нисколько: enigo под MIT‑лицензией — можно бесплатно использовать. Взамен — звёзды на GitHub и счётчик загрузок.

Интересно, что Claude Desktop — Electron‑приложение, но есть только для macOS и Windows. Сообщество запустило его на Linux, заменив вызовы enigo заглушками, хотя enigo кроссплатформенна — любопытный выбор.

Через знакомых я узнал об открытой роли в команде, делавшей секретную, ещё не выпущенную функцию Claude Desktop с enigo. Подал заявку, ждал. В итоге пришло письмо: команда не успевает рассматривать дополнительные заявки.

Я бы с радостью поработал в Anthropic: сделать аналог Computer Use, довести Claude Desktop до Linux, вложить свой опыт в эмуляцию ввода и полноценно отполировать enigo, чтобы Anthropic концентрировалась на моделях, а не на капризах ввода.

В целом я счастлив, что enigo в Claude Desktop, и всем об этом рассказываю. Забавно думать, что я метафорически дал Claude руки и ноги — и получить отказ. Письмо написал человек или сам Claude? По крайней мере, теперь я, наверное, в безопасности…

• Обсуждение вокруг автора OSS-библиотеки enigo, которую, по словам поста, использует Claude Desktop; при попытке податься в Anthropic он получил авто‑отказ без рассмотрения, что вызвало резонанс.
• Многие считают, что заявку, вероятно, даже не читали из‑за перегруженных или автоматизированных HR/ATS‑процессов; советуют искать тёплый интро к менеджеру, а не подаваться «в общий ящик».
• Поднята тема лицензий: permissive (MIT) позволяет корпорациям брать код без вклада; участники предлагают рассмотреть MPL/EUPL, Fair Source или даже целевые ограничения, хотя применимость и исполнение спорны.
• Несколько комментаторов призывают Anthropic хотя бы поблагодарить автора, дать консультационный контракт или символическую компенсацию; другие напоминают, что компания волна отбирать кого хочет.
• Обсуждаются возможные факторы отказа: геолокация (США vs Европа), визы, несоответствие профиля «AI‑инженеру», парадоксы найма и предпочтение «низкопрофильных» кандидатов.
• Приводятся похожие кейсы из индустрии: от игнора мейнтейнеров до неудачных интервью у компаний, зависящих от их софта.
• Общий вывод: современный тех‑набор страдает от автоматизации и перегрузки; для кандидатов критичны нетворкинг, прямой контакт с нанимающим менеджером и стратегия видимости, а для OSS — осознанный выбор лицензии.

!Изображение 1: обложка

Переосмысление DOM с нуля

!Изображение 2: обложка

Браузеры в странном положении: WebAssembly выстрелил, даже на сервере, а клиентская часть ощущается почти как 10 лет назад. Доступ к веб-API из WASM решают тонким JS-клеем — но зачем вообще лезть в DOM? Просто других опций нет. Пора отправить DOM и его API «на ферму», и вот почему.

Никто уже не знает браузеры целиком — и это часть проблемы.

!Изображение 3: Netscape

Модель «документа»

Мало кто осознает, насколько DOM раздут. У document.body в Chrome 350+ ключей, а в document.body.style — около 660 свойств. Граница между свойствами и методами размыта, геттеры могут триггерить релэйаут, висят легаси-штучки вроде onevent. DOM толстеет; страничникам это почти не видно, а приложениям — боль.

Большинство избегают прямой работы с DOM; деклартивности мало и она несовременна. Способов сделать одно и то же много, ни один не приятен.

connectedCallback() {
  const shadow = this.attachShadow({ mode: 'closed' });
  const template = document.getElementById('hello-world').content.cloneNode(true);
  const hwMsg = `Hello ${ this.name }`;
  Array.from(template.querySelectorAll('.hw-text')).forEach(n => n.textContent = hwMsg);
  shadow.append(template);
}

Веб-компоненты пришли поздно, непопулярны: API громоздкий, Shadow DOM плодит уровни вложенности и области видимости. Главная беда — строковая наследственность SGML/XML: состояние хранить в документе плохо; React-подобные это избегают, их «XML» — лишь синтаксис.

!Изображение 5: W3C
!Изображение 6: WHATWG

HTML почти не менялся 10–15 лет. ARIA стала заплаткой тому, что не дала «семантика HTML». Цели так и не достигли: нет <thread> или <comment>, правила странные. WHATWG (то есть вендоры) добавляет лишь заплатки по краям; даже CSS оброс выражениями — любая шаблонка хочет стать языком программирования.

!Изображение 7: Netscape Composer

Редактируемость HTML через contentEditable — теоретически есть, практически — темная магия; у команд Docs/Notion наверняка кошмары. Догмы про «прогрессивное улучшение» и разделение разметки/стилей в мире приложений мало кто исповедует.

Сегодня приложения склеивают HTML/CSS/SVG до «достаточно красиво», ценой огромных оверхедов — это анти-UI тулкит.

!Изображение 8: редактор Slack
Подпись: Ввод Slack

!Изображение 9: хак с раскладкой
Подпись: Оффскрин-хаки для буфера обмена

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

!Изображение 10: кружка “css is awesome”

CSS вывернут наизнанку

CSS не имеет стройной…

• Участники признают, что веб-платформа сложна и разрослась из-за обратной совместимости, множества требований и долгой эволюции; переписывание «с нуля» в реальности лишь добавляет новые слои сложности.
• Многие защищают DOM/HTML/CSS: они кроссплатформенны, поддерживают доступность, приватность, IME/спеллчек и текстовые сценарии, с которыми канвас/кастомные рендеры часто не справляются.
• Критика фокусируется на перегруженности API, «текучих» абстракциях и смешении ролей (CSS как и стиль, и лейаут), предлагаются идеи модульности API, хранение состояния в документе, и дисциплинированное использование Web Components.
• Аргумент «выбросить и заменить» упирается в стоимость миграции и необходимость покрыть весь исторический функционал; успех веба объясняют именно гибкостью, хаками, позже закреплёнными стандартами, и жёсткой обратной совместимостью.
• Проводят параллели с нативными UI-стеками: многие считают веб-технологии более удачными; обсуждают Flutter/WASM/WebGPU как путь к «приложенческому» вебу без ломания существующего.
• Идеи разделения «документы vs приложения» всплывают часто (вплоть до «DOCTYPE app»), но консенсус: нужно сосуществование обоих подходов, а не замена.
• Скепсис к «HTML на Canvas» и «перезапуску браузера» высок: полезнее усиливать существующие примитивы (дешёвый доступ WASM к DOM, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.

These examples show that we have a serious social issue, and it's not limited to teachers. People misuse LLMs. We engineers understand that LLMs are products under development. They only work correctly under certain circumstances, and they have limitations and non-perfect evaluat

• State-of-the-art модель TTS до 25 МБ 😻
• Пропустить к содержимому
• Навигация, вход, настройки внешнего вида
• Продукты: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search
• Исследовать: Почему GitHub, все функции, документация, навыки, блог
• Решения по размеру компании: Enterprise, для команд, стартапов, НКО
• По задачам: DevSecOps, DevOps, CI/CD и др.
• По индустриям: здравоохранение, финансы, производство, гос сектор
• Ресурсы: темы (ИИ, DevOps, безопасность, разработка), курсы, события, книги, истории клиентов, партнёры, аналитика
• Open Source: Sponsors, ReadME Project
• Репозитории: Темы, Тренды, Коллекции
• Enterprise: платформа, допы — Advanced Security, Copilot for business, поддержка
• Цены
• Поиск кода и репозиториев, советы по синтаксису
• Обратная связь (с email), отправка/отмена
• Сохранённые поиски: создание/управление, документация по синтаксису
• Вход/регистрация
• Сообщения о перезагрузке сессии и переключении аккаунтов
• KittenML/KittenTTS (публичный), уведомления, форки

• Обсуждение вращается вокруг KittenTTS — очень маленькой (порядка десятков МБ), автономной TTS-модели с лицензией Apache-2.0, работающей на CPU и пригодной для встраивания в недорогие устройства; отмечают веб-демо и аудио-примеры на Reddit.
• Бенчмарки на i9-14900HX: стартовая задержка ~315 мс, генерация 3.3–5.5x реального времени в зависимости от длины текста; модель грузится быстро.
• Мнения разделились по качеству: многие впечатлены для такого размера и офлайн-режима, но ряд пользователей критикуют «металличность», проблемы с числами и короткими фразами, и считают качество ниже Piper/Kokoro/XTTS; в сравнении упоминают более качественные, но тяжелые fish-speech и F5-TTS (GPU).
• Практические вопросы: сложности с установкой зависимостей и версиями Python, запросы на ONNX/gguf-порты, аудиосэмплы на главной странице, мультиязычность и тренировочный код/датасеты, а также офлайн STT (часто советуют Whisper).
• Преимущества, которые подчеркивают: полностью офлайн, легкая интеграция, отсутствие лицензионных рисков, пригодность для встраиваемых/батарейных устройств и доступности; потенциально меняет «проблему железа/лицензий» на «проблему упаковки».
• Есть интерес к будущим версиям (например, 80M модель для лучшей выразительности), к локальному клонированию голосов и к снижению латентности для естественных диалогов.
• В целом консенсус: не SOTA по естественности, но выдающееся соотношение размер/скорость/лицензия для множества офлайн use-case’ов.

Я архивирую Picocrypt · Issue #134 · Picocrypt/Picocrypt

===============

Пропустить к содержимому
Меню навигации

Переключить навигацию

Войти

Настройки внешнего вида

• Продукт
• GitHub Copilot Пишите код лучше с ИИ
• GitHub Spark Новое Создавайте и внедряйте интеллектуальные приложения
• GitHub Models Новое Управляйте и сравнивайте подсказки
• GitHub Advanced Security Находите и исправляйте уязвимости
• Actions Автоматизируйте любые процессы
• Codespaces Мгновенные среды разработки
• Issues Планируйте и отслеживайте работу
• Code Review Управляйте изменениями кода
• Discussions Сотрудничество вне кода
• Code Search Ищите быстрее и точнее

Исследуйте

• Почему GitHub
• Все возможности
• Документация
• GitHub Skills
• Блог

• Решения

По размеру компании

• Предприятия
• Малые и средние команды
• Стартапы
• НКО

По кейсам

• DevSecOps
• DevOps
• CI/CD
• Все кейсы

По отраслям

• Здравоохранение
• Финансовые услуги
• Производство
• Госструктуры
• Все отрасли

Все решения

• Ресурсы

Темы

• ИИ
• DevOps
• Безопасность
• Разработка ПО
• Все темы

Изучайте

• Обучающие маршруты
• События и вебинары
• Ebooks и whitepapers
• Истории клиентов
• Партнеры
• Executive Insights

• Open Source
• GitHub Sponsors Поддержка разработчиков
• The ReadME Project Материалы сообщества

Репозитории

• Темы
• В тренде
• Подборки

• Enterprise
• Платформа для разработчиков на базе ИИ

Дополнения

• Advanced Security Корпоративная безопасность
• Copilot for business Корпоративные ИИ-возможности
• Премиум-поддержка 24/7

• Цены

Поиск или переход...

Поиск кода, репозиториев, пользователей, issues, pull requests...
==========================================================

Поиск

Очистить

Советы по синтаксису

Оставить отзыв
================

Мы читаем каждый отзыв и относимся к нему серьезно.

• [x] Указать мой email для связи

Отмена Отправить отзыв

Сохраненные поиски
==============

Используйте сохраненные запросы для быстрого фильтра

Название

Запрос

Все квалификаторы в документации.

Отмена Создать сохраненный поиск

Войти

Зарегистрироваться

Настройки внешнего вида

Сброс фокуса

Вы вошли в другой вкладке. Перезагрузите страницу, чтобы обновить сессию. Вы вышли в другой вкладке. Перезагрузите страницу. Вы переключили аккаунты. Перезагрузите страницу. Закрыть уведомление

{{ message }}

Picocrypt/Picocrypt Публичный

• Уведомления

• Обсуждение вокруг автора проекта Picocrypt, который архивирует репозиторий и уходит из разработки из-за разочарования в «вибе-кодинге» и доминировании ИИ/LLM, оформлено как диалог с Gemini, что некоторых сбило с толку.
• Часть комментаторов сочувствует утрате «ремесленного» подхода и демотивации, другие считают реакцию чрезмерной, доomer-ной или попыткой личного брендинга.
• Спор о лицензиях: MIT критикуют как «слабую» (корпорации выигрывают), предлагают AGPL/SSPL и обсуждают бессмысленность запрета «обучения ИИ» из-за непроверяемости корпусов.
• Поднимаются вопросы ответственности перед донорами на аудит и ожиданий сообщества: код доступен, но без поддержки возникают риски багов/совместимости.
• Есть технические замечания к проекту (напр., зависимость от OpenGL на macOS, результаты VirusTotal) и альтернативы (7zip, VeraCrypt); некоторые форкают и планируют упростить GUI.
• Мнения о LLM: от полного отказа и счастья без них до признания их неизбежности как «массового производства кода»; отмечают, что ИИ не делает людей экспертами, и традиционные инструменты часто надежнее.
• Отмечают парадокс: критикуя ИИ-кодинг, автор собирается в исследование LLM; часть видит в этом стратегию карьеры и нехватку ресурсов на опенсорс, а не «конец качества».

UKR almost feels like yesterday's drone war. It seems pretty obvious purpose built murder bots by technologically capable powers like PRC would be fully autonomous and expendable like actual munitions. Image fuse some cheap rgb/ir/thermo with edge compute to maim any warm bodies

I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wi