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

В марте 2026 года две независимые группы объявили о результатах, которые заметно сокращают разрыв между теорией и реальными машинами. Звёздная команда квантовых физиков из Калифорнийского технологического института (Калтеха) представила проект квантового компьютера, способного взламывать шифрование RSA и ECC всего лишь с помощью десятков тысяч кубитов, и заявила о создании компании для его разработки. А исследователи из Google объявили о разработке реализации алгоритма Шора, которая в десять раз эффективнее лучшего из предыдущих методов.

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

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

Меня зовут Рене, я сетевой инженер в FirstVDS. В прошлой статье я рассказывал, как мы переезжали из euNetworks в QupraDC и почему даже маленькую площадку полезно строить как нормальную фабрику, а не как одну большую коробку на всё.

Сначала я не планировал писать отдельную статью про второй переезд. Со стороны всё выглядело слишком похоже: снова Amsterdam, снова EVPN/VXLAN‑фабрика, снова временная связность между дата‑центрами и постепенный перенос серверов. Казалось, что получится пересказ той же истории другими названиями площадок.

Но повод был уже другим. В мае‑июле 2026 года в Qupra DC2 произошла серия отказов системы охлаждения: оборудование уходило в аппаратную защиту от перегрева, а локация получала многочасовую недоступность. Аномальная жара стала триггером, но не единственной причиной нашего переезда: единичный сбой превратился в целый каскад проблем, которые вскрыли инженерные и эксплуатационные просчёты площадки. После этого ждать гарантий или доработок со стороны дата‑центра мы не считали надёжным планом. Решение было простым и неприятным: надо переезжать в другой ДЦ.

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

Если речь идёт о текстовых сообщениях, помогут каналы связи, созданные с помощью технологии LoRa.

В этой статье мы разберёмся с темой обмена сообщениями через LoRa. Начнём с простого мессенджера, позволяющего обмениваться сообщениями между двумя компьютерами с разъёмами USB под управлением Windows или Linux. Затем перейдём к мессенджеру с  микрокомпьютером Raspberry Pi.

В итоге мы создадим несложную mesh-сеть с ретрансляцией по принципу флуда и TTL-ограничением на микроконтроллерах ESP32-S3-N16R8 и модулях LoRa E22-900T22D. Каждый узел этой сети будет поднимать собственную точку доступа Wi-Fi с веб-интерфейсом чата. Для подключения к узлу и обмена сообщениями достаточно обычного смартфона с браузером. В качестве дополнения сделаем так, чтобы в этой сети можно было работать и с компьютера под Windows, к которому подключён LoRa USB-донгл E22-900T22U.

Когда речь заходит о разработке PHP-расширений, многие сразу представляют C, Zend API и сложную систему сборки. Но сегодня есть более удобный путь. С помощью ext-php-rs можно создавать расширения на Rust, используя привычные инструменты Cargo и практически не сталкиваясь с низкоуровневыми деталями.

В этой статье мы с нуля напишем собственный PHP-экстеншен, подключим его к PHP, разберём, как ext-php-rs связывает Rust с Zend API, а затем посмотрим, в каких задачах такой подход действительно даёт прирост производительности, а где этого ждать не стоит.

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

CTE в PostgreSQL упрощают код, но могут снижать производительность. Разбираем 4 антипаттерна, примеры EXPLAIN ANALYZE и практические способы оптимизации.

В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE. 

Common Table Expressions (CTE), или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть.

Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики.

Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.

В предыдущей статье я рассказывал о том, как предоставить удалённый доступ к данным измерений метеостанции с помощью модулей Heltec Automation HTIT-WB32LAF V3, объединяющих микроконтроллер ESP32-S3FN8 с LoRa-чипом SX1262. При правильной установке антенн и хороших условиях распространения радиоволн возможна передача данных на километры.

Но что, если нужно передавать данные ещё дальше, а возможности антенн с большим коэффициентом усиления исчерпаны и мощность передатчика повышать нельзя? 

В этот раз я пришёл с двухчастным текстом про F#, тайппровайдеры, скрипты, спортивное программирование, MVU, консольные интерфейсы в стиле FarManager, низкоуровневый интероп с виндой, некоторое количество хаков ХМ и, внезапно, живопись. Причём только консольные интерфейсы с некоторой натяжкой можно назвать центральным элементом повествования, поэтому я понятия не имею, как должен выглядеть потенциальный читатель этой статьи. Будем исходить из предположения, что он либо достаточно опытен, либо у него достаточно времени и усердия, чтобы расковырять всё, что я не счёл должным разобрать детально (я могу, но только за 16 глав).

Сегодня мы изучим небольшой .fsx-скрипт, который я ежедневно запускаю, чтобы получить очередную порцию задачек из архива codeforces.com. Необычно то, что скрипт функционирует как полноценное GUI-приложение, пусть и очень страшное старое. Кажется, что до меня так никто не делал, так что с осторожностью назову это авторской инновацией.

Секрет попал в Dockerfile, разработчик спохватился и добавил RUN rm. Файла в контейнере больше нет — значит, всё в порядке? Нет: строку по-прежнему можно достать из образа, даже не запуская контейнер. Я собрала восемь образов, в каждом передала секрет своим способом и разобрала результат на слои и метаданные. Ниже — где именно оседает секрет в каждом случае и какие два способа действительно не оставляют следов.

Все эксперименты выполнены на Ubuntu 24.04.1 LTS, Docker Engine 29.1.3, BuildKit v0.26.2.

Vue снова меняет способ обновления интерфейса: теперь на горизонте Vapor и рендеринг без Virtual DOM. Зачем очередная архитектурная перестройка и что не устраивает команду Vue в нынешнем подходе?

Чтобы ответить, проследим путь Vue от Object.defineProperty до Proxy  и зачем теперь понадобился Vapor. Это поможет лучше понимать поведение ref, reactive и computed, вникнуть в причины архитектурных изменений Vue и подготовиться к дальнейшим изменениям.

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

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

Совместное исследование DDoS-Guard и FirstVDS

Раньше считалось, что DDoS-атаки направлены на «крупную рыбу» — корпорации, госкомпании, банки. Но реальность 2026 года говорит о другом: жертвой злоумышленников может стать кто угодно.

За три года число атак выросло с 2,2 до 2,5 млн. Их распределённость увеличилась на 480%. DDoS-атаки стали массовым, доступным и, что самое опасное, автоматизированным инструментом. 

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

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

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

Ранее в своих статьях я рассказывал, как подключать модули EBYTE LoRa к Raspberry Pi и Repka Pi (ссылки в конце этой статьи). Но такие микрокомпьютеры потребляют довольно много электроэнергии и не «проживут» долго на аккумуляторе. 

Сами по себе модули LoRa в спящем режиме весьма экономны и могут годами работать на автономном питании, если после передачи данных «засыпают» на длительное время. Но вся эта экономия сработает, только если они будут управляться микроконтроллерами, способными переходить в спящий режим и просыпаться по таймеру.

В этой статье на примере метеостанции я расскажу о том, как создавать узлы сбора данных LoRa на базе микроконтроллера ESP32-S3, установленного в модуле Heltec Automation HTIT‑WB32LAF V3. Микроконтроллер может переходить в состояние глубокого сна, когда работают только часы реального времени и память RTC, а вся периферия отключается. В результате узел сбора данных может работать очень долго, питаясь от аккумулятора.

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

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

Зато судьбы учёных они меняют легко.

В конце 1990-х годов, когда физики неожиданно обнаружили, что нейтрино обладают массой, Тьерри Лассерр оставил космологию, чтобы полностью посвятить себя изучению элементарных частиц. «Это было так захватывающе, что я просто не смог устоять», — сказал Лассерр, ныне физик в Институте ядерной физики Общества Макса Планка в Гейдельберге, Германия. А Марк Росс-Лонерган собирался стать метеорологом, пока в 2010 году случайно не столкнулся с физикой частиц и не изменил своё решение. Лассерр, Росс-Лонерган и тысячи других учёных посвятили карьеру исследованию этой почти инертной частицы.

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

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

В статье соберем полностью локальную RAG-систему на Go, PostgreSQL и Ollama без облачных API и сторонних сервисов. Разберем весь путь — от индексации документов до получения ответа LLM на основе найденного контекста.

Это первая статья в серии про LoRa — технологию передачи данных, способную работать с сигналами ниже уровня шума. Протокол LoRa позволяют передавать данные на километры с очень небольшой мощностью передатчика — порядка 10 мВт или 10 дБм. При этом модули LoRa потребляют так мало энергии, что могут работать от одной зарядки аккумулятора год или больше.

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

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

Из этой статьи вы узнаете, как появились устройства LoRa и почему они могут принимать сигналы ниже уровня шума. Вы узнаете, как работать с модулями LoRa, подключенными к микрокомпьютеру Raspberry Pi, научитесь конфигурировать эти модули с учетом ограничений законодательства, а также передавать с их помощью сообщения на километры. В завершение статьи я расскажу, как сделать простую погодную станцию, измеряющую температуру, давление и влажность. Данные будут передаваться через LoRa и отображаться на OLED-мониторах, подключенных к передатчику и приёмнику.

Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию.

Если вы не читали первую часть, лучше начать с неё: в ней разобрали принципы расследования, изоляцию хоста, trusted toolkit, фиксацию исходного состояния, сетевые соединения и процессы. Без этого контекста часть команд и логика дальнейшего анализа будут менее понятны.

Первая часть здесь.

В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.

Пару лет назад я уже публиковал статью о реагировании на инциденты в Linux-системах. Она по-прежнему может быть полезна как практическая шпаргалка, но с тех пор изменился и мой опыт, и требования к таким материалам. В этом цикле статей  я хочу разобрать Linux live response более системно. 

Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. 

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

Добро пожаловать под кат. 

Способен ли маленький нетбук принести хоть какую-либо пользу в 2026 году?

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

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

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

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