Denis Evsyukov

Как оставить свои AI-модели в VS Code без Copilot

denis@evsyukov.org (Denis Evsyukov) — Thu, 24 Sep 2026 16:47:53 +0300

Я много лет пользуюсь VS Code и синхронизировал настройки через GitHub. Входишь в аккаунт на новой машине — возвращаются настройки и расширения. Но доступ к Copilot Pro у меня пропал, а сам Copilot продолжал предлагать автодополнение там, где я его не просил. При этом отказываться от AI в редакторе я не хотел: для работы с агентами мне нужны собственные модели, в том числе DeepSeek и Z.ai.

В VS Code есть настройка chat.disableAIFeatures, но она отключает и скрывает встроенные AI-функции целиком, включая чат. Мне же нужно было сохранить чат со своими моделями и перестать пользоваться сервисом Copilot.¹

При чём здесь синхронизация

Для Settings Sync VS Code предлагает вход через GitHub или Microsoft. Я использовал GitHub, поэтому редактор уже имел доступ к моей учётной записи. Copilot тоже использует вход через GitHub. Это разные функции: смена аккаунта для синхронизации сама по себе не означает выход из GitHub во всём редакторе.²³

Я вышел из GitHub в редакторе и перенёс синхронизацию на учётную запись Microsoft. Такой вариант сохраняет Settings Sync и позволяет работать в чате с моделями, добавленными через собственные ключи или совместимый endpoint. Для этого не нужен план Copilot.⁴

Как я переключил синхронизацию

Открыл меню Accounts и полностью вышел из учётной записи GitHub через Sign out. Это выход из GitHub в VS Code, а не только из Copilot; он затрагивает и другие расширения, использующие этот аккаунт.³
Открыл Command Palette и выполнил Settings Sync: Turn Off. Удалять синхронизированные данные из облака для смены аккаунта не требуется.²
Перезапустил Extension Host командой Developer: Restart Extension Host, затем окно командой Developer: Reload Window.
Выбрал Manage → Backup and Sync Settings..., указал, что синхронизировать, и вошёл через Microsoft в браузере.

С первого раза синхронизация у меня выдала ошибку. Повторный запуск Backup and Sync Settings... завершился успешно. Перезапуск Extension Host и окна — часть моих действий, а не обязательные шаги из документации VS Code: для смены аккаунта она предписывает выключить Settings Sync и включить его с другим аккаунтом.²

При первом включении синхронизации с другой учётной записью VS Code объединяет локальные данные с данными в облаке. Если там уже есть настройки и редактор показывает конфликт, нужно выбрать нужную версию или сравнить обе; подтверждать замену вслепую не стоит.²

После переключения Settings Sync работал через Microsoft, а GitHub в редакторе не был авторизован. Проверить это можно в меню Accounts: если GitHub там всё ещё указан, нужно выйти из него отдельно. Одна только смена аккаунта Settings Sync не гарантирует выхода из GitHub, и Copilot может продолжить использовать этот вход.³

Что осталось работать

После переключения мои модели доступны в чате VS Code, а предложения Copilot при наборе кода больше не появляются. Здесь есть ограничение: модели, добавленные через собственные ключи, работают в чате и связанных с ним задачах, но не заменяют встроенное автодополнение Copilot. Для inline suggestions по-прежнему требуется сервис GitHub Copilot.⁴

Таким образом, для моей задачи хватило разделить два входа: синхронизировать настройки через Microsoft и не держать GitHub авторизованным в VS Code. Если позже снова войти в GitHub ради другого расширения, стоит проверить, не вернулись ли предложения Copilot.

Читайте оригинал на странице: Как оставить свои AI-модели в VS Code без Copilot (Denis Evsyukov)

Ссылки #408

denis@evsyukov.org (Denis Evsyukov) — Sat, 19 Sep 2026 09:22:03 +0300

За прошедшую неделю собрал 45 ссылок.

🔐 Безопасность

How Trail of Bits helps verify the integrity of your Signal chats Как устроена автоматическая проверка публичных ключей в Signal и зачем ей независимые аудиторы. Trail of Bits рассказывает о своей реализации, которая помогает обнаружить подмену ключей со стороны сервера.

Switching Password Managers in 2026 Рики Монделло показывает, как на iPhone перенести пароли, passkeys и коды подтверждения напрямую между менеджерами паролей, без промежуточных файлов. Заодно объясняет, почему после переезда стоит сохранить старое хранилище как резервную копию.

Inside ZCode: Silently Uploading Your Entire Git History to the Cloud Автор разобрал ZCode и обнаружил фоновую отправку проекта в облако вместе с полной историей Git. По его наблюдениям, переключатели в настройках управляют обучением моделей и индексацией, но не отключают саму загрузку.

🤖 Искусственный интеллект

Notes on migrating 35kb prompts away from Anthropic/OpenAI to Self-Hosted Ollama+opencode Опыт переноса больших промптов с Anthropic и OpenAI на локальную связку Ollama и opencode. Автор столкнулся с переполнением контекста и повторяющимися вызовами инструментов. Предлагает разбивать инструкции на отдельные задачи и сохранять состояние работы на диск.

DeepSeek V4.1 Flash is Now Our Best Hacking Model В тестах Enclave модель добилась выполнения кода на всех 11 уязвимых стендах. Разбор показал, что в пяти случаях она использовала неожиданные пути в тестовом окружении, поэтому авторам пришлось уточнить проверки в benchmark.

🛠 Инфраструктура

Alternatives to MinIO for single-node local S3 Сравнение S3Proxy, RustFS, SeaweedFS и других замен MinIO для локального S3. Автор проверяет работу с DuckDB и Iceberg, приводит примеры Docker Compose и разбирает сложность настройки на одном узле.

На этой неделе в подборке: проверка ключей в Signal, смена менеджера паролей, скрытая отправка истории Git в ZCode, перенос промптов на локальные модели, DeepSeek в тестах на взлом и альтернативы MinIO.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #408 (Denis Evsyukov)

Ссылки #407

denis@evsyukov.org (Denis Evsyukov) — Sat, 12 Sep 2026 10:22:36 +0300

За прошедшую неделю собрал 85 ссылок.

🔌 Железо

Home Hardware, Part 2: Width Matters Джесс Фрейз спорила с коллегой о расчёте импеданса 50 Ом для RF-трассы на четырёхслойной плате Sensor Hub: разница в 0,1164 мм до внутреннего слоя земли вместо 0,2064 мм меняла ширину дорожки с 0,1778 мм до 0,32 мм. Оказалось, KiCad показывал оба внутренних слоя с медью земли, а агент Codex подобрал ближайший стек JLC04161H-2116 и пересчитал ширину, но итоговый файл содержал 0,18 мм — компромисс между вариантами с боковой землёй и без неё. Теперь она переводит платы на два слоя, чтобы сэкономить на серийных заказах.

🛡️ Инфраструктура

Understanding the recent DDoS attack against Read the Docs В июне 2026 года Read the Docs пережил крупнейшую DDoS-атаку: 5,5 млн запросов в минуту — в 100 раз выше обычного трафика. Атака длилась десять дней, использовала миллионы уникальных IP, рандомизацию TLS и HTTP-заголовков, а также целенаправленно била по некэшируемым URL (404, 302). Команда перенесла часть редиректов на Cloudflare, добавила «штрафные» правила для подозрительных запросов и агрессивнее кэшировала даже короткоживущие ответы, избежав массовых JS-челленджей для пользователей.

🔐 Криптография

I’ve factored the RSA keys of a Certificate Authority… В 1999 году Netscape 4.51 поставлял корневые сертификаты удостоверяющего центра E-Certify с 512-битными RSA-ключами для SSL и S/MIME — слабыми даже по меркам того времени. Автор нашёл архивы старых браузеров на archive.org, извлёк сертификаты с помощью Claude Code и факторизовал оба ключа на Ryzen 9 5950X за 32 и 29 часов с помощью CADO-NFS, получив приватные ключи. Теперь их можно использовать для выпуска сертификатов в Netscape 4.51 с датой до 16 октября 2003 года или для атаки «человек посередине» на пользователей этого браузера.

🦀 Раст

Visualizing Rust’s Vtables: How dyn Trait Works In Memory Чтобы понять, как работает dyn Trait в Rust, автор разбирает в памяти vtable — структуру, которая хранит указатели на реализации методов трейта для конкретного типа. Для &dyn Draw компилятор генерирует wide pointer из двух указателей: на данные объекта и на vtable, общий для всех объектов одного типа. В отличие от C++, где vtable встраивается в объект, в Rust он создаётся отдельно и подключается только при динамическом диспатче, а выбор между статическим и динамическим диспатчем делается на уровне вызова.

🤖 Агенты

The irrational effectiveness of the Pi harness Редактор опробовал минималистичный coding harness Pi на TypeScript, чтобы уйти от раздутых и непрозрачных систем вроде Claude Code и Codex. В Pi всего четыре инструмента — read, write, edit и bash, — а системный промпт занимает около 1000 токенов против 4400 у Codex; за месяц ежедневного использования автор не вернулся к более навороченным альтернативам. Для своих задач он написал несколько расширений: skill:whip для чистки LLM-текстов, extension:web.ts для поиска через DuckDuckGo и extension:subagent для запуска агентов в отдельных процессах.

⚡ Квантизация

Benchmarking Qwen3.8 27B quantizations: 4-bit holds up, 1-bit collapses - Quesma Blog Qwen3.8 27B в квантовании Q4_K_M (17 ГБ) на бенчмарках Terminal-Bench 2.1 и GPQA Diamond показывает результаты, неотличимые от полной BF16-модели (55 ГБ), при этом влезает на RTX 4090 с запасом на 64k токенов контекста. Двухбитная UD-Q2_K_XL (10,7 ГБ) проседает на 5–10%, но всё ещё сравнима с Opus 4.7, а однобитные модели падают до уровня случайного угадывания — особенно на длинных рассуждениях. Тесты обошлись в $3000 на аренде GPU через Modal, где 4-битная модель оказалась в 1,6 раза дешевле полной.

На этой неделе в подборке: 50-омная RF-трасса на четырёхслойной плате, разбор июньской DDoS-атаки на Read the Docs, факторизация 512-битных RSA-ключей CA из Netscape 4.51, устройство vtable у dyn Trait в Rust, минималистичный coding harness Pi и бенчмарки квантований Qwen3.8 27B.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #407 (Denis Evsyukov)

Почему исправный прокси был недоступен из контейнеров Podman

denis@evsyukov.org (Denis Evsyukov) — Fri, 11 Sep 2026 19:01:41 +0300

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

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

Почему долго искали не там

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

Проверки с хоста этому противоречили: прокси принимал соединения, внешние адреса отвечали. Но проверка с хоста пропускала часть пути, по которому шёл запрос приложения. Для rootless-контейнера между приложением и хостом находились дополнительные сетевые компоненты.

В рассматриваемой схеме путь выглядел так:

flowchart TB app[Приложение в контейнере] --> bridge[Bridge и NAT] bridge --> pasta[pasta] pasta --> proxy[Прокси на хосте]

Здесь pasta связывает виртуальный сетевой интерфейс namespace с обычными сокетами хоста. У него есть собственная таблица соединений: успешного ответа прокси с хоста недостаточно, чтобы подтвердить исправность всего пути.¹

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

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

Как нашли механизм отказа

SYN выходит из контейнера, но соединение на хосте не появляется

Следующим шагом стали одновременные захваты пакетов в rootless namespace и на хосте. В момент отказа со стороны контейнера были видны повторные SYN. Это первые пакеты TCP handshake: клиент просит установить соединение и повторяет попытку, если не получает ответа.

Пакеты проходили bridge и NAT, но соответствующего соединения к процессу прокси на хосте не возникало. Трассировка системных вызовов pasta не показывала нового connect() для этой попытки. Значит, искать причину отказа именно этого подключения на внешнем маршруте было преждевременно: оно до него ещё не дошло.

Это также отделяло проблему от HTTP и TLS. Приложение не успевало отправить запрос или начать защищённое соединение. Проверка ключей доступа и настроек внешнего API ничего не объяснила бы.

Отказ зависел от исходного порта

Обычно приложение позволяет ядру выбрать свободный source port. Мы стали задавать его явно и повторять подключения к одной и той же цели.

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

Смена контейнера не обязательно меняла эту комбинацию для pasta. После NAT разные адреса контейнеров могли превращаться в один адрес, видимый сетевому компоненту. Поэтому пересоздание контейнера не гарантировало освобождения занятой записи.

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

Старое соединение занимало место нового

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

Проблемным подключениям соответствовали старые записи. На стороне хоста сокеты находились в CLOSE_WAIT: удалённая сторона уже прислала FIN, но локальная сторона ещё не завершила свою половину соединения. Pasta передал FIN клиенту и получил подтверждение, однако запись продолжала существовать без обмена данными гораздо дольше ожидаемого.

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

Получив новый SYN, pasta находил старую запись и передавал пакет обработчику уже установленного соединения. Для исследованного состояния и sequence numbers тот не создавал новое соединение и не формировал ответ. Клиент продолжал повторять SYN до таймаута. Это объясняло и зависимость от source port, и отсутствие connect() на хосте.

Таймер, который постоянно откладывал очистку

Оставалось понять, почему записи не удалялись. В старом коде был таймер очистки после двух часов бездействия. Существенная часть обработчика выглядела так:

timerfd_settime(conn->timer, 0, &new, &old);
if (old.it_value.tv_sec == ACT_TIMEOUT)
 tcp_rst(c, conn);

К моменту вызова таймер уже сработал. Код снова заводил его на два часа и проверял, равно ли прежнее значение двум часам. Но timerfd_settime() возвращает в old.it_value оставшееся время. У только что истёкшего таймера там ноль, поэтому условие очистки не выполнялось.²

Этот механизм мог повторяться неограниченно: очередное срабатывание переносило очистку ещё на два часа. Описание upstream-исправления подтверждало ту же ошибку.³

Мы отдельно собрали маленькую C-программу и повторили последовательность вызовов timerfd с коротким начальным ожиданием. После срабатывания прежнее оставшееся время было нулевым, ветка очистки не выбиралась. Это позволило проверить понимание системного вызова, не меняя таймеры работающего процесса.

При этом исходный эпизод незавершённого закрытия восстановить не удалось: захвата пакетов за тот момент не было. Мы установили причину удержания старых записей и отказа новых SYN. Утверждать, что конкретный FIN потеряла сеть или приложение, оснований не было.

Как обновляли и проверяли исправление

Что собирали, а что взяли готовым

Upstream уже удалил неработающий механизм и добавил периодический обход таблицы: соединения без активности удаляются через два–четыре часа. Дополнительно появились TCP keepalive в сторону клиента. Если клиент уже забыл соединение, он отвечает RST, и запись можно убрать раньше.⁴⁵

Эти изменения вошли в релиз 2026_05_07.1afd4ed.⁶ Для проверки мы выбрали более свежий официальный Debian-пакет с исправлениями. Из исходников мы собрали диагностические программы. Для самого passt использовали готовый .deb, полученный через APT с проверкой подписи репозитория и контрольных сумм пакета.

Свежего пакета не было в подключённом стабильном репозитории. Нужную сборку взяли из Debian sid через отдельные временные индексы, не добавляя sid в постоянные источники системы. До установки проверили зависимости и запустили симуляцию APT. Она должна была показать обновление только passt, без попутной замены системных библиотек.⁷

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

Сначала пришлось исправить сам тест

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

Для этого мы создали отдельную rootless-сеть и локальный TCP-сервер с коротким тестовым ответом. Сервер отправлял FIN, клиент подтверждал его, после чего удалял свой сокет через TCP_REPAIR, не отправляя FIN или RST. Pasta должен был остаться с записью о соединении, которого клиент уже не помнил.

Первый вариант теста оказался неверным. Клиент удалял сокет слишком быстро, до отправки отложенного ACK на FIN. Получалась проверка повторной передачи неподтверждённого FIN, а не очистки нужного нам состояния. Разницу показал захват пакетов.

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

Проверка	Результат
Старая версия	Удерживала соединение всё время наблюдения, больше десяти минут
Новая версия до установки	Удалила соединение примерно за 32 секунды; повторное подключение с тем же портом прошло
Новая версия после установки	Повторила результат, в том числе с действующим профилем AppArmor

В захвате новой версии была видна вся последовательность: keepalive, RST от ядра клиента, затем новый успешный handshake. В выбранном июльском релизе интервал проверки клиента уже сокращён до 30 секунд, что согласуется с результатом опыта.⁸

Этот тест проверяет обнаружение соединения, забытого клиентом. Он не означает, что любое бездействующее TCP-соединение новая версия закрывает через полминуты.

Обновить файл недостаточно

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

В проверенной версии Podman был путь восстановления: при обращении к общей rootless-сети он мог обнаружить остановленный сетевой процесс и запустить новый в существующем namespace. Сначала мы испытали это в отдельной сети и убедились, что namespace, bridge и доступ к хосту сохраняются.⁹

Затем завершили только нужный процесс pasta, дождались его выхода и вызвали podman unshare --rootless-netns true от того же пользователя. Podman поднял новый процесс. Пересоздавать контейнеры не понадобилось, но текущие внешние TCP-соединения при такой замене обрываются: состояние старого pasta в новый процесс не переносится.

Это описание проверенного способа восстановления, а не универсальная команда перезапуска сети для любой версии Podman. Перед применением нужно установить, какой процесс обслуживает нужный namespace и как конкретная версия восстанавливает его после остановки.

После переключения мы проверили те самые комбинации портов, которые раньше стабильно давали timeout. Соединения устанавливались сразу. Затем проверили SOCKS, HTTP CONNECT, прямые запросы из контейнера, IPv6 и доступ к тестируемым приложениям. Состояния контейнеров и их сетевые адреса сравнили с исходными.

У установки отдельного пакета осталась эксплуатационная особенность: постоянный источник sid не подключён, поэтому следующие его версии обычный APT сам оттуда не получит. За дальнейшими исправлениями passt придётся следить отдельно.

Что из этого следует

Главный результат расследования — воспроизводимый отказ и проверенное изменение его механизма. До обновления старая запись удерживалась, после обновления pasta обнаруживал, что клиент её забыл, и освобождал комбинацию адресов и портов. Это сильнее, чем серия успешных запросов после перезапуска.

Для диагностики полезнее всего оказалось сравнение одного и того же пути в исправном и неисправном состоянии. Проверка с хоста отвечала на свой вопрос, но ничего не говорила о прохождении запроса через rootless-сеть. Явно заданный source port превратил случайный симптом в повторяемый опыт, а чтение исходников объяснило результат.

Есть и архитектурный вывод. Отсутствие общего демона управления контейнерами не означает отсутствия общих зависимостей. В конфигурации с общим pasta сетевой процесс может влиять сразу на несколько независимых приложений. Проверка доступности должна проходить через тот же сетевой путь, которым пользуются эти приложения.

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

Примечание. Статья написана gpt-6-astra по результатам работы на сервере.

passt и pasta: устройство и назначение . ↩︎
timerfd_create, timerfd_settime, timerfd_gettime , Linux man-pages. Поле old_value.it_value содержит оставшееся время. ↩︎
Удаление неработающего inactivity timeout , commit upstream. ↩︎
Периодическая очистка неактивных соединений , commit upstream. ↩︎
Keepalive для обнаружения забытых клиентом соединений , commit upstream. ↩︎
Bug 179, комментарий о выпуске исправления . В исходном обращении обсуждалось состояние FIN_WAIT_2; сопоставлялся механизм очистки, а не полное совпадение симптомов. ↩︎
Пакет passt в Debian sid . ↩︎
tcp.c в релизе 2026_07_28.f8df3f1 , KEEPALIVE_INTERVAL и tcp_keepalive(). ↩︎
Восстановление общего rootless namespace в containers/common v0.62.3 , getOrCreateNetns(). ↩︎

Читайте оригинал на странице: Почему исправный прокси был недоступен из контейнеров Podman (Denis Evsyukov)

Ссылки #406

denis@evsyukov.org (Denis Evsyukov) — Sat, 05 Sep 2026 09:38:54 +0300

За прошедшую неделю собрал 59 ссылок.

🤖 Агенты

Grep beats LSP? Why coding agents ignore your fancier tools — AgentConnect Blog Автор сравнил поиск через grep и инструменты на основе LSP в небольшом исследовании с тремя моделями Claude. Когда агентам нужно было найти участок кода, они выбирали LSP лишь в 0–6% случаев. Требование сначала использовать LSP снижало долю успешно выполненных задач со 100% до 89%. При поиске всех вызовов функции LSP исключал ложные совпадения, но с обоими инструментами агенты находили лишь около двух третей вызовов. Для переименования grep оказался полезен ещё и потому, что находит упоминания в комментариях и строках, которые find_references пропускает. На результат влиял и формат ответа инструмента: когда к координатам найденного кода добавили по две строки до и после совпадения, доля успешных переименований с первой попытки выросла с 67% до 83%. После этого агенты реже открывали файлы повторно.

🛡️ Безопасность

Breaking Claude Code Opus 5 Auto Mode · Embrace The Red Исследователь показал, как просьба кратко пересказать страницу приводит к выполнению вредоносного кода в Claude Code с Opus 5. Защита Auto Mode не остановила атаку: в этом режиме команды вместо пользователя одобряет классификатор безопасности. После ошибки WebFetch агент сам переходит на curl и скачивает ZIP-архив. Он отказывается запускать приложенный декодер и пишет свой на Python, но запускает его из каталога распакованного архива. При импорте base64 Python загружает оттуда подменённый struct.py, и код атакующего получает управление. В зависимости от варианта атака сработала в трёх или четырёх из пяти запусков. Иногда агент замечал проблему, однако Auto Mode блокировал попытку остановить вредоносный процесс. В Anthropic закрыли отчёт со статусом Informative и пояснили, что защиту должны обеспечивать изоляция средствами ОС и контроль сетевого доступа. Классификатор таких гарантий не даёт.

🔎 Поиск

A third of Perplexity’s citations don’t contain the number they’re cited for — Haus Research Исследователи из Haus Research проверили ссылки на источники в ответах Perplexity. Моделям sonar и sonar-pro задали 310 вопросов о 210 технологических компаниях, затем открыли указанные страницы и сопоставили числа в них с числами в ответах. Из 1826 ссылок, которыми модели подкрепляли утверждения с числами, 34,7% вели на недоступные страницы или на страницы без единого совпадения. У одного утверждения могло быть несколько источников, и для зачёта хватало хотя бы одного с совпавшим числом. По этому критерию проверку не прошли 14,4% из 872 утверждений. Нередко ссылка открывалась, но нужных сведений на странице не было: например, Perplexity ссылался на Wikipedia, указывая адреса Docker и Substack, которых в этих статьях нет. Sonar-pro в этой проверке показал примерно тот же результат, что и sonar. Даже совпадения года было достаточно, поэтому успешное прохождение ещё не означает, что источник подтверждает всё утверждение.

🏠 Локальные модели

Run Qwen3.8 27B locally: real numbers from my Mac Studio | TerminalBytes Автор использует Qwen3.8 27B на Mac Studio для повседневных задач: модель готовит утреннюю сводку из RSS, переименовывает отсканированные PDF и пересказывает длинные обсуждения. Он сравнил её с Qwen3.6 27B на Mac Studio M3 Ultra с 256 ГБ общей памяти, выполнив по пять замеров. В варианте Q4_K_M через Ollama новая модель генерирует 14 токенов в секунду против 28,6 у предыдущей. При этом её ответы заметно короче, поэтому на готовый ответ уходило примерно столько же времени. Однобитная версия от Unsloth размером 6,7 ГБ работала быстрее, но застревала в рассуждениях: выдав правильную команду bash, продолжала перебирать альтернативы и не могла закончить ответ. В статье также есть таблица требований к памяти: для Q4 автор рекомендует 32 ГБ. Для задач с вызовом инструментов он ссылается на рекомендацию Unsloth использовать как минимум Q2_K_XL.

🌐 Сеть

Internet centralization and the original sin of NAT Автор связывает централизацию интернета с распространением NAT. Эту технологию предложили в 1994 году как временный способ экономить IP-адреса: несколько устройств используют один публичный адрес. Однако без дополнительной настройки маршрутизатор не знает, какому устройству передать новое входящее соединение. В статье разобраны способы обойти это ограничение и их недостатки. Проброс портов на домашнем маршрутизаторе не решает проблему NAT у провайдера, STUN помогает не при всех типах NAT, а TURN передаёт трафик через промежуточный сервер и добавляет задержку. IPv6 позволяет обойтись без NAT, но его внедрение затянулось, а ограничения на входящие соединения нередко сохраняются. По мысли автора, эти сложности приучили нас обращаться к облачным сервисам: даже для своего небольшого сервера часто проще арендовать VPS, чем сделать домашний компьютер доступным извне.

🔍 Приватность

Firefox’s AI Switch Is Off. Telemetry Isn’t. Мариус Квабек повторил в Firefox 155 проверку переключателя, отключающего AI-функции. Он создал два новых профиля и сравнил их сетевой трафик в Wireshark: с настройками по умолчанию и после отключения AI. Переключатель теперь охватывает больше функций, включая Smart Window, но отправка телеметрии и обращения к рекламным серверам продолжаются. За две минуты простоя оба профиля отправили по 14 запросов с телеметрией; после перезапуска идентификаторы профиля также сохранились. При первом запуске браузер запросил настройки ai-window-prompts ещё до того, как пользователь получил доступ к переключателю. Автор отдельно оговаривает: Mozilla не обещает отключать им телеметрию и рекламу. Его претензия в том, что пользователю трудно понять границы этой настройки и разобраться, какие данные браузер продолжает отправлять.

В этой подборке: выбор между grep и LSP для агентов, обход защиты Auto Mode в Claude Code, проверка источников Perplexity, опыт работы с Qwen3.8 27B на Mac Studio, влияние NAT на централизацию интернета и отправка телеметрии после отключения AI в Firefox.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #406 (Denis Evsyukov)