Сохранёнки программиста

Почему запросы на staging укладываются в 12 мс, а в продакшене встают колом

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

В материале: от параноидального создания индексов «на всякий случай» до игнорирования раздутия и мультитенантных схем. Каждый INSERT, UPDATE и DELETE обновляет все индексы таблицы, а индекс на колонке с низкой селективностью бесполезен без частичного (partial) условия. Внешние ключи в PostgreSQL не индексируются автоматически, а без EXPLAIN ANALYZE индексы создаются вслепую.

Сохранить стоит разработчикам бэкенда и администраторам БД с production под нагрузкой. Остальным достаточно знать, что индексы — налог на запись, а не волшебная ускорялка.

Читать разбор на Tproger

Один клик по ссылке — и у атакующего твой GitHub-токен на чтение и запись всех репозиториев, включая приватные

Ammar Askar разобрал цепочку, которая складывается из вполне безобидных по отдельности фич. Началось всё с github.dev — это лёгкий VSCode прямо в браузере, который открывается, если в адресе репозитория поменять github.com на github.dev. Чтобы он мог коммитить и слать pull request от твоего имени, github.com по сети передаёт ему OAuth-токен. И вот ключевая деталь: токен не привязан к конкретному репозиторию. Он даёт доступ ко всему, к чему есть доступ у тебя.

VSCode рендерит превью Markdown и Jupyter-ноутбуки внутри webview — это iframe с отдельным origin, отрезанный от основного окна. Идея правильная: даже если в ноутбуке выполнится произвольный JavaScript, до ядра редактора он не дотянется. Но есть нюанс удобства. Чтобы горячие клавиши работали, когда фокус внутри webview, VSCode вешает там слушатель keydown и пробрасывает нажатия в основное окно сообщением did-keydown. Основное окно принимает их за реальный ввод пользователя. А значит, скрипт из недоверенного webview может сам сгенерировать keydown и «нажать» клавиши за тебя.

Дальше Askar обходит защиты одну за другой, и это самая поучительная часть:

🔘Палитру команд (Ctrl+Shift+P) открыть получается, но напечатать в неё текст нельзя: поле ввода слушает не keydown, а обычный HTML-input, до которого синтетические события не доходят
🔘Тогда в дело идут встроенные хоткеи VSCode, которые висят прямо на keydown. Через .vscode/extensions.json репозиторий рекомендует «своё» расширение, всплывает уведомление, а Ctrl+Shift+A («принять основное действие уведомления») жмёт кнопку установки
🔘Система доверия к издателю (с версии 1.97) показала бы диалог подтверждения, но кнопку в нём синтетическим Enter не нажать. Обход — local workspace extensions: расширение прямо в .vscode/extensions в доверенном workspace ставится без проверки издателя, а github.dev доверенный всегда
🔘Последний барьер, CSP, ломал прямую загрузку. Решение изящное: расширение через package.json регистрирует свой keybinding на runCommands, который вызывает workbench.extensions.installExtension с флагом skipPublisherTrust. Своё нажатие клавиши воспроизводится железно, так что устанавливается уже что угодно

Итоговый payload прячется в Markdown-ячейке ноутбука как картинка с onerror, ждёт всплывающего уведомления, шлёт Ctrl+Shift+A, затем Ctrl+F1, и установленное расширение читает OAuth-токен и дёргает api.github.com за списком приватных репозиториев. CSRF-токенов у github.dev нет, поэтому редиректнуть жертву на атаку может любая ссылка.

Отдельно ценен раздел про то, что VSCode сделал правильно: именно defense-in-depth спас от худшего сценария. На странице расширения скрипты в Markdown-превью отрублены через script-src 'none', иначе это была бы 1-click RCE на десктопе. Microsoft выкатил фикс на следующий день (3 июня): подтверждение при открытии ноутбуков в вебе и запрет пробрасывать keydown из webview ноутбука.

Если защищаешься: очисти cookies и site data для github.dev. Тогда при заходе появится диалог, на котором можно уйти со страницы до запуска цепочки.

Сохранять тем, кто пишет приложения с webview, разбирает модели изоляции iframe или просто любит, когда сложную атаку собирают из десятка «удобных» мелочей.

https://blog.ammaraskar.com/github-token-stealing/

@prog_stuff

ИИ-агент для аналитики бесполезен, если он не понимает ваши данные

Cloudflare написали production-разбор про Town Lake и Skipper. Снаружи это похоже на историю «мы дали модели доступ к SQL». Но главный смысл как раз в обратном: ИИ-агент для данных начинается не с промпта, а с платформы, которая объясняет ему схемы, владельцев, права, свежесть таблиц и смысл колонок.

Контекст большой: больше миллиарда событий в секунду, 330+ городов, Postgres, ClickHouse, Kafka, BigQuery, R2 и внутренние пайплайны. Town Lake собирает это в единый SQL-интерфейс через Trino. DataHub хранит схемы и происхождение данных. Lifeguard управляет доступами. Skimmer ищет персональные данные. А Skipper уже поверх этого превращает вопросы на естественном языке в проверяемые SQL-запросы.

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

Где держать Telegram-бота или API, чтобы они не падали под нагрузкой и не съедали бюджет?

Tproger собрал подборку из шести VPS-провайдеров под этот сценарий: от тарифов за пару сотен рублей в месяц до конфигураций с DDR5 и портом 10 Гбит/с. У каждого свой акцент — где-то посуточная оплата и запуск за минуту, где-то API для CI/CD, бэкапы и приватные сети, где-то зарубежные локации.

Внутри по каждому провайдеру: реальные конфигурации, цены, на какой нагрузке тестировали и под какой сценарий брать.

https://tproger.ru/articles/gde-razvernut-bota-ili-api---podborka-vps--kotorye-ne-tormozyat

@prog_stuff

Почему передача репозитория не равна передаче проекта

Programming as Theory Building — классический текст Питера Наура о том, что программирование не сводится к коду, документации и диаграммам. Всё это важные артефакты, но они не содержат всю «теорию» системы.

Главное в тексте — очень точное объяснение боли legacy: проект можно формально передать полностью, но новая команда всё равно не получит систему. Репозиторий есть, README есть, схемы есть, backlog есть, а уверенности в изменениях нет.

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

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

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

https://pages.cs.wisc.edu/~remzi/Naur.pdf

Эссе Марка Брукера, инженера в AWS, с неожиданным выводом о том, какие задачи окажутся для ИИ-агентов лёгкими, а какие трудными. И ключ тут вовсе не в интеллекте модели.

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

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

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

Это уже заметно. Агенты сильны в оптимизации производительности, где есть бенчмарки. Rust своими явными ошибками компиляции буквально ведёт агента к корректному коду. Property-based тесты бесценны. А вот с архитектурой беда: тут обратная связь в духе «пойму, когда увижу». И с конкурентным кодом так же, там ошибка молча портит данные в рантайме.

Дальше самое интересное. Сравните две задачи: сверстать приятный фоторедактор в вебе и написать корректный высокопроизводительный движок хранения для базы данных. Кажется, первое проще. Но по гипотезе Брукера в долгую проще как раз второе. У движка БД есть чёткая спецификация: API, гарантии безопасности и живучести, и итерироваться к успеху можно вообще без участия людей. А «приятный» сайт упирается в человека в петле, а человек медленный и непоследовательный судья.

Вывод переворачивает привычную интуицию: SaaS и интерфейсы окажутся трудными, а системный софт лёгким. И на первый план выходит спецификация, умение записать, что значит «хорошо», плюс инструменты, которые это проверяют: Rust, Verus, TLA+, симуляторы, моки. Сама по себе генерация кода становится вторичной.

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

https://brooker.co.za/blog/2026/05/18/whats-easy-whats-hard.html

@prog_stuff

Большой разбор Cloudflare, почему серверы начали грузиться по четыре часа

Cloudflare разобрали, как обычное обновление firmware превратило перезагрузку bare-metal серверов в многочасовое ожидание. Отличный пример того, как маленькая деталь в UEFI boot order ломает rollout почти на 2 000 машин.

Суть проблемы: после обновления firmware серверы проходили POST нормально, но потом линейно перебирали неподходящие варианты сетевой загрузки. IPv4 HTTPS boot, IPv4 iPXE, снова таймауты — и только потом рабочий IPv6 HTTPS boot. Каждый неудачный network boot съедал примерно по 5 минут. На одном reboot неприятно, а в firmware upgrade automation, где несколько компонентов обновляются через последовательные перезагрузки, это раздувалось почти до 4 часов.

В разборе показывают путь расследования:

🔘 serial console вместо гадания по мониторингу;
🔘 как UEFI, PXE, iPXE и HTTPS boot участвуют в загрузке;
🔘 почему firmware начал перебирать интерфейсы не в том порядке;
🔘 как Cloudflare стала задавать network boot interface order заранее в pre-boot PXE stage;
🔘 какие ограничения всплыли: старые UEFI-версии не поддерживают boot ordering, а настройки могут сбрасываться после firmware upgrade;
🔘 как всё завели через существующий release pipeline без ручного похода в BIOS.

Главная цифра: firmware upgrade automation сократили с почти 4 часов до 3 минут, а последующий single boot — примерно с 20 минут до менее чем минуты.

Сохранять тем, кто отвечает за bare metal, firmware updates, PXE/iPXE-загрузку или просто любит production-разборы, где проблема прячется не в коде приложения, а в цепочке до старта ОС. Тут хорошо видно, почему boot order, таймауты и vendor quirks стоит тестировать так же внимательно, как обычный rollout.

@prog_stuff

Обстоятельная статья о том, что нужно, чтобы быстро транспонировать матрицу. Андрей Гудков берёт самую наивную реализацию на C++ (два вложенных цикла, dst[c,r] = src[r,c]) и шаг за шагом разгоняет её на x86_64 до 25 раз.

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

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

🔘Наивная версия как точка отсчёта.
🔘Разворот порядка обхода.
🔘Блочная разбивка матрицы под размер кэш-линии.
🔘Программный префетч.
🔘 Векторизация на 64-битном SIMD, потом на 256-битном.
🔘 Буферизация вывода.

Полезного по дороге много. Например, наглядно показано, во сколько обходится промах кэша: попадание в L1d почти бесплатно (4-5 тактов), L2 уже 12-15, L3 — 40-45, а промах до RAM стоит до 300 тактов. И что любой доступ к одному байту на самом деле тянет в кэш всю 64-байтную линию, поэтому весь фокус в том, чтобы успеть подгрузить данные заранее.

Хорошее чтение на вечер, если интересна low-level оптимизация под x86_64. Со схемами, анимацией обхода кэша и кодом каждой версии.

https://gudok.xyz/transpose/

@prog_stuff

Попалась статья, где автор нам напоминает про недооценённый файл в Linux — /proc/<pid>/mem. Через него можно читать и записывать память любого процесса в реальном времени.

Просто cat /proc/self/mem выдаёт ошибку ввода-вывода. Чтобы добраться до данных, нужно сначала сделать lseek на нужное смещение, а потом read или write — либо сразу передать смещение через pread/pwrite. После этого можно вытащить или поменять содержимое памяти.

Зачем это нужно: снять «слепок» памяти зависшего приложения и восстановить данные, обойти антиотладку или просто заглянуть процессу внутрь. Стандартный отладочный интерфейс ptrace умеет то же самое через PTRACE_PEEKDATA и PTRACE_POKEDATA, но работать с ним заметно муторнее.

В 2002 году автор написал на этой механике утилиту memfetch для съёмки памяти процесса, а на выходных обновил её под современные 64-битные системы. Бонусом — история про то, как в Linux 2.2 можно было вызвать mmap на этом файле и подвесить всю систему.

@prog_stuff

Tproger собрал разбор облачных провайдеров для хостинга 1С на 2026 год.

Внутри простым языком: какие облака подходят для 1С, зачем смотреть на CPU, NVMe, SLA, резервные копии, 152-ФЗ и поддержку миграции.

@prog_stuff

AI Engineer — не переименованный ML-инженер и не разработчик с доступом к API LLM. Это самостоятельная дисциплина со своим мышлением и метриками

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

ML-инженер живёт в модельном слое: датасеты, обучение, архитектура. AI Engineer берёт готовую модель и превращает её в продукт. Разница сидит не в коде, а в слое ответственности. Цикл сборки, оценки и улучшения не заканчивается никогда, и главная сложность в том, чтобы выбрать правильные метрики качества.

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

Сенсоры maintainability: как не дать ИИ-агентам нарастить техдолг

Подробный гайд про контроль качества кода от генеративных агентов — стоит сохранить, если вы используете Claude, Cursor или Copilot в production. В материале на martinfowler.com Birgitta Böckeler из Thoughtworks показывает, как окружить агента системой ограничений и проверок.

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

Unicode 18.0 готовится к релизу 15 сентября 2026 года. Сейчас это beta/draft, но набор новых символов уже заморожен.

Главное: стандарт добавляет 13 047 символов. Всего в Unicode будет 172 848 символов.

Что появится:

🔘 4 новые письменности: Chisoi, Jurchen, Seal и архаические клинописные числа.
🔘 Seal — самое крупное добавление: больше 11 тысяч символов древней китайской «малой печати».
🔘 Эмодзи тоже обновятся: cracking face, жесты большим пальцем влево/вправо, гусеница монарха, pickle, маяк, метеор, ластик и сачок.

Для разработчиков важнее не эмодзи. Unicode 18 меняет правила переноса строк, разбиения текста на графемы, сортировки, security/confusables и variation sequences.

Это может влиять на поиск, username, домены, markdown/rendering, редакторы, шрифты, regex и любые системы, которые режут текст «по символам».

Обычным приложениям можно ждать, пока Unicode 18 доедет через ОС, браузеры, ICU и языковые рантаймы. А если вы делаете редактор, текстовый движок, font tooling, security-проверки идентификаторов или поддержку CJK, beta уже стоит прогнать на тестах.

@prog_stuff

Ваша память ещё работает или нейронки уже и помнят всё за вас?

Чтобы это проверить мы приготовили для вас «Меморину» — игру, которая поможет проверить вашу память.

Всё просто: нужно запомнить и выбрать одинаковые карточки. Если память плохая, то рано или поздно вы всё равно справитесь. А если хорошая, то сможете увидеть ваш потолок скорости.

Ну что, готовы проверить? Тогда переходите по ссылке: https://tprg.ru/cyhK

Как вызвать API из письма без JavaScript — инженер из Redo рассказывает, как они шлют миллионы интерактивных писем (отложить подписку, отменить заказ) без редиректа и скриптов.

Подход — два несвязанных куска:

🔘AMP Email от Google. Работает в Gmail и Yahoo, итого около 25% покрытия. Автор честно расписывает, чем AMP бесит: жёсткая валидация, нет :has, prefers-color-scheme, !important, @keyframes, ::before/::after, баги годами не чинят, одобрение домена занимает пять дней через Google Form с CAPTCHA.
🔘CSS-трюки добивают покрытие до 70%. Прячем <input type="checkbox">, связываем с <label>, а в #cb:checked ~ .card { background-image: url(...); } подсовываем URL своего API. Браузер лениво загружает картинку только после клика — это и есть тихий GET-запрос. Сервер отдаёт прозрачный пиксель и делает нужный side effect.

Подвохи у CSS-фокуса:

🔘ловится только первый клик по кнопке. Обходится цепочкой одинаковых кнопок, которые скрывают предыдущую и показывают следующую;
🔘поведение лениво подгружаемого background-image не специфицировано. Теоретически Apple Mail может однажды начать бот-кликать CSS-урлы, как уже делает с <img>. У Redo на этот случай висит «Interactive Email Doomsday» мониторинг.

В тексте есть рабочий пример карточки «отложить подписку на неделю или месяц» с полным HTML и CSS, копируется и работает в AMP, Apple Mail, Thunderbird и новом Outlook.

Полная статья: https://redo.com/eng-blog/how-to-call-an-api-from-an-email/

@prog_stuff

Багу MySQL #11472 — почти 21 год.

Закрыт в этом году.

В июне 2005 года Omer Barnir сообщил: если строки в child-таблице меняются из-за каскадной FK-операции на parent-таблице (ON DELETE CASCADE, ON UPDATE CASCADE, ON DELETE SET NULL), триггеры AFTER DELETE/UPDATE на child-таблице не вызываются. Баг получил severity S2 (Serious). Каждые пару лет в комментариях появлялись новые сообщения от разработчиков: аудит-логи и денормализованные колонки в child-таблицах не отражали реальных изменений после каскада на parent.

Причина архитектурная: каскады обрабатывались внутри InnoDB, а триггеры живут на SQL-уровне сервера. Engine-level каскады просто не могли вызвать триггер. В 2009-м баг переоткрывали в 5.1, в 2010-м обещали починить в форке lp:6.1-fk.

Что починили:

- в MySQL 9.6 ввели SQL-layer foreign key handling, переменная innodb_native_foreign_keys; при OFF каскады выполняются на уровне сервера и можно вызвать триггер;
- в MySQL 9.7 добавили opt-in переменную enable_cascade_triggers; при ON и при отключённых native FK в InnoDB BEFORE/AFTER триггеры на child-таблицах вызываются для DELETE/UPDATE CASCADE и SET NULL;
- цепочка каскада ограничена 30 таблицами на одно выражение, чтобы триггер на child не мог войти в бесконечную рекурсию через parent;
- транзакционная семантика сохранена: ошибка в триггере откатывает всё SQL-выражение.

Включается per session, по умолчанию выключена. Приложения, которые годами рассчитывали на текущее поведение, по умолчанию не ломаются.

Баг-репорт: https://bugs.mysql.com/bug.php?id=11472
Разбор от Oracle: https://blogs.oracle.com/mysql/no-more-silent-foreign-key-cascades-mysql-9-7-lets-child-triggers-speak-up

@prog_stuff

Lock-free очередь на C++ с нуля — подробный разбор того, как собрать MPMC-очередь, которая обгоняет std::queue под std::mutex в восемь раз при 16 потоках.

Автор идёт от наивной реализации к финальной и на каждом шаге объясняет, что и почему ломается:

🔘mutex-вариант разваливается из-за context switch в ядре;
🔘наивный CAS-подход спотыкается о ABA и use-after-free;
🔘батчинг по 1024 слота на узел убирает аллокатор с горячего пути и чинит cache locality;
🔘hazard pointers безопасно освобождают память без локов;
🔘thread-local кэш узлов окончательно убирает кучу с быстрого пути.

По ходу хорошо разобраны мелочи: alignas(64) против false sharing, выбор между compare_exchange_strong и weak, индивидуальный подбор acquire/release/relaxed/seq_cst под каждую операцию, паттерн DEFER в духе Go для парного Protect/Release.

Бенчмарки на 5 млн элементов и 16-ядерном CPU:

🔘2P/2C — 150 мс против 250 мс у мьютекса;
🔘8P/8C — 309 мс против 2152 мс;
🔘16P/16C — 299 мс против 2600 мс;
🔘1P/8C — 254 мс против 3138 мс.

В конце автор замечает: для пары потоков std::mutex остаётся правильным выбором, lock-free нужен там, где много контеншена — рендеринг, HFT, аудио, массовый ingestion.

Полная версия: https://jaysmito.dev/blog/blog/04-fast-lockfree-queues/

@prog_stuff

Как ломаются мобильные приложения: пять багов на стыке систем

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

Перечислять конкретные кейсы не буду, лучше сразу статью глянуть: https://tproger.ru/articles/kak-lomayutsya-mobilnye-prilozheniya

@prog_stuff

Саймон Уиллисон выступил на PyCon US 2026 с пятиминутным докладом про последние полгода в LLM, а потом разложил всю презентацию с комментариями к каждому слайду. Получился сжатый, но плотный обзор с ноября 2025 по май 2026.

Главная мысль: ноябрь 2025 года стал точкой перелома, особенно для агентов-программистов. До ноября они «часто работают». После ноября они «работают почти всегда» и могут стать основным инструментом, не отнимая половину времени на правку их ошибок.

Условное звание «лучшей модели» сменило хозяина пять раз за полгода: Claude Sonnet 4.5, потом GPT-5.1, дальше Gemini 3, GPT-5.1 Codex Max, и наконец Anthropic вернул лидерство с Opus 4.5. Уиллисон тестирует это всё на личном бенчмарке «сгенерируй SVG пеликана на велосипеде»: задача, под которую ни одна лаборатория модели не обучает.

Второй большой тренд: модели с открытыми весами выросли быстрее ожиданий. Gemma 4 от Google, крупнейшая серия с открытыми весами от американской лаборатории. GLM-5.1 от китайской GLM, открытая модель на 1,5 ТБ. И Qwen3.6-35B-A3B на 20,9 ГБ запускается на ноутбуке Уиллисона и рисует пеликана лучше, чем Claude Opus 4.7.

Февральская часть посвящена «эпохе Claws»: после OpenClaw и подобных персональных ИИ-агентов в индустрии прижился общий термин Claws. Mac Mini начали раскупать в Силиконовой долине именно под локальный запуск этих агентов.

Полный разбор со слайдами и оригинальными подписями: https://simonwillison.net/2026/May/19/5-minute-llms/

@prog_stuff

Как российская антивирусная индустрия выросла из дискет

На Tproger вышла вторая часть истории российского IT, про 90-е и нулевые. Один из больших разделов — про то, как защита от вирусов из академического побочного проекта превратилась в экспортную технологию.

В начале 90-х вирусы расползались через дискеты: принесли программу, заодно принесли вирус. Чем больше компьютеров появлялось в офисах и институтах, тем быстрее расходились заражённые файлы.

Первой отечественной попыткой был Tadpole, затем антивирусный сканер Tornado, которые потом объединились в Spider's Web. В 1993 году появился Dr.Web, а в 1994-м вышла его первая коммерческая версия.

Параллельно Евгений Касперский после работы в НИИ Министерства обороны ушёл в коммерческий IT, занимался антивирусами в КАМИ и в итоге собрал собственную фирму. Самое интересное случилось в 1996–1997: команда договорилась с иностранными вендорами, и зарубежные антивирусные продукты стали использовать российский движок внутри. Технология заработала на экспорт раньше, чем большая часть индустрии.

В этом же материале: про Контур и переход налоговой на дискеты, рождение Rambler и Яндекса, дефолт 1998 года и появление первых онлайн-банков.

Полная статья: https://tproger.ru/articles/kakim-bylo-it-v-90-h-i-nulevyh-modemy-kompy-defolt-i-pervye-o

@prog_stuff