dxdt.blog: занимательный интернет-журнал

В августе 2010 года, пятнадцать лет назад, в небольшой заметке про DNSSEC, я, действуя несколько неосторожно, предположил буквально следующее:

До нового Интернета остались такие шаги (думаю, в таком порядке, как они перечислены дальше): DNSSEC на клиентах (года два на выполнение), строгое подписывание анонсов BGP и криптографическое удостоверение AS-ок (три-пять лет), переход подавляющей части трафика на IPv6 (пять-семь лет). А может даже и раньше.

Интересно сравнить с реальностью в 2025 году.

DNSSEC на клиентах

Да, тут было очень активное движение в обозначенную сторону. Сделали плагины для браузеров, например. Даже сперва всё уложилось в те самые два года, но, к сожалению, распространения не случилось и постепенно тема замылилась, пусть и не погасла совсем. То есть, что уж там в 2012, но сказать, что DNSSEC повсеместно внедрена на клиентах даже в 2025 году, конечно, нельзя: ландшафт тут вообще перекосило в другую сторону (см. ниже), а технология-то DNSSEC и в DNS-зонах не получила распространения, куда уж там клиентам.

Однако настроить клиентскую поддержку всё же можно, да и движение с переносом валидации на клиента, пусть и самое минимальное, но пока сохраняется: см. например, systemd-resolved в современных линуксах. Что ещё по этой теме есть сейчас? Ну, в те же браузеры собственный интерфейс “DNS-резолвинга” таки встроили, но это DNS over HTTPS/DNS over TLS, где проверка DNSSEC оставлена внешнему провайдеру. Это не очень-то хорошо, но что же поделать? Как минимум, TLS тут даёт какой-то инструмент для трансляции доверия. В общем, если вычесть всякие технологические оговорки, массовое внедрение “DNSSEC на клиентах” не случилось, сейчас его нет, так что прогноз про два года, строго говоря, не оправдался. Да и DNSSEC, из-за своей хрупкости, вообще не пользуется спросом в непростое время сегментации интернетов.

Строгое подписывание анонсов BGP и криптографическое удостоверение AS

“Подписывание анонсов” – это имеется в виду “сквозной” и строгий вариант sBGP, когда каждый “хоп” ставит проверяемую подпись. Не случилось. Подвижки тут тоже есть (BGPsec, SIDR Ops и др.), но пока даже нет причин говорить, что реализация как-то близка. Причины банальные, как ни странно: мало кому это нужно; как и в случае с DNSSEC – технология хрупкая, это многих пугает; большой риск централизации – тоже не особо хорошо в ситуации, когда идёт битва за банхаммер.

Сейчас одна деятельная сторона, – которая есть исторически сложившаяся, старая часть основателей интернетов, – укрепляется во мнении, что “это наша сеть, в которую мы если разрешаем подключиться кому-то ещё, то только тем, кто себя ведёт так, как мы считаем правильным, и при этом не топчет мрамор пола пусть и чистыми, но всё равно же – лаптями”, а главное – сохранить возможность разрешать подключение на основании детектирования типа обуви. Другая деятельная сторона – ещё хитрее: эта сторона использует глобальность Сети для создания собственных “больших интранетов”, чему немало способствует деятельность стороны первой: потому что вы не можете строить локальный сегмент, когда нет нужной глобальности, относительно которой сегмент и определяется, как локальный. В общем, битва кита со слоном и океан замутила, и на суше подняла пыль: ситуация в целом не очень-то хорошая складывается, так что не до подписывания анонсов BGP. Подписывания нету, и в этой части – прогноз не сработал совсем.

Зато вот с “криптографическим удостоверением AS”, которое есть RPKI (удостоверение при помощи цифровой подписи права быть источником (origin) для IP-префикса), прогресс за пятнадцать лет очень большой: поддержка RPKI для IP-префиксов не только перестала быть исключительной редкостью на стороне AS, но даже и для фильтрации реально используют (но не все, не везде). Вероятно, так случилось потому, что RPKI – несколько более централизованная технология. Так что в этой части, хоть и не через “три-пять” лет, но прогноз близок к реальности.

IPv6 как транспорт для подавляющей части трафика

Тут я уже осторожно указал дистанцию в пять-семь лет по времени, и через пятнадцать лет у нас трафик по IPv6 в Интернете большой, но не подавляюще большой. Популярность IPv6 выросла очень сильно, факт, но этот протокол “всё ещё продолжает идти на смену IPv4” (как вы знаете, адреса для последнего за это время успели закончиться раз пять или семь, как раз по числу лет в интервале ожидания моего прогноза). В общем, нельзя сказать, что совсем не сработал этот прогноз – использование IPv6, как и количество передаваемого по этой версии IP-трафика, в 2017 году относительно 2010 возросло в разы, а ещё больше – сейчас, в 2025. Однако не похоже, что прогноз сработал полностью: для dxdt.ru всё ещё нет AAAA-записи (но есть один авторитативный NS с AAAA).

Интернет сильно поменялся. Особенно, за пять лет периода 2020-2025. Но эта записка посвящена ретроспективе заметок dxdt.ru, так что обсуждение прочих изменений – оставим для других записок.

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

С синтезированием апертуры связан ещё один интересный аспект: для синтезирования необходимо движение, но двигаться может не только радар. Напротив, двигаться, относительно радара, – и, обычно, некоторого “фона”, подстилающей поверхности, – может наблюдаемая цель, а её движение как раз создаст “базу” для синтезирования сигнала. Это метод обратного синтезирования апертуры. Алгоритмы используются существенно более сложные, но метод неплохо подходит для распознавания и классификации типов движущихся целей. Особенно, на море, в отношении больших кораблей. Поэтому использованием обратного синтезирования особенно известен штатовский P-8 Poseidon – морской самолёт радиолокационного наблюдения, на котором применяется специальная, подвешиваемая под фюзеляж, наружная система РЛС AN/APS-154 (AAS).

Обратное синтезирование позволяет получить достаточно высокую разрешающую способность, которая, при этом, ещё и мало зависит от дальности до цели. Представьте, что радар принимает сигнал, отражённый некоторым объектом, имеющим достаточно большие линейные размеры. Пусть на объекте установлены какие-то мачты или башенки. Не так важно, что именно – главное, чтобы были геометрически обособленные элементы. Если этот объект движется относительно приёмника радара, то в разные моменты времени углы, под которыми со стороны приёмника видны эти элементы, будут меняться. Ещё лучше, если объект вращается: тогда и скорость изменения углов вырастет, и существенная разность возникнет для многих элементов. И изменение углов, и относительное движение элементов объекта, возникающие в системе координат, привязанной к приёмнику радара, означают, что во времени будут изменяться характеристики отражённого разными элементами зондирующего сигнала: будет сдвигаться фаза, изменяться частота (доплеровский сдвиг).

Синтезирование апертуры подразумевает запись сигналов на протяжении некоторого интервала времени – интервала синтезирования. Отдельные элементы реальных объёктов – это их, так сказать, упрощённое “пиксельное” представление, используемое в расчётах: в современной вычислительной радиолокации, естественно, нет никаких непрерывных областей пространства или непрерывных сигналов – всё разбивается на дискретные элементы, как по времени, так и по частоте. Соответственно, вычислитель приёмника, синтезируя записанные сигналы, использует изменения фазы и частоты, чтобы при помощи цифровой обработки собрать размытые сигналы в общий результат, с высокой разрешающей способностью.

Вообще, при обычном (прямом) синтезировании, достаточно быстро движущиеся цели дают “растянутые” вдоль некоторой траектории отметки, поскольку на интервале синтезирования успевают изменить пространственное положение (за этим эффектом стоит несколько способов селекции движущихся целей). И вот обратное синтезирование позволяет такие отметки собрать в единое изображение с дополнительными деталями. Современные радары – вычислительные, так что методы прямого и обратного синтезирования могут применяться РЛС параллельно и синхронно (см. ниже).

Понятно, что многие типы целей заведомо содержат элементы, за которые можно хорошо “зацепиться” при обработке: летательные аппараты, находящиеся в воздухе, активно маневрируют, а вертолёты ещё и быстро вращают лопастями. Корабли – раскачиваются на волнах, это эквивалентно вращению, а надстройки, мачты, антенны – всё, таким образом, даёт сильные “разностные” сдвиги: при определённых ракурсах наблюдения и движении корабля – разные отметки, соответствующие элементам конструкции, могут вообще двигаться в разных направлениях (относительно приёмника, конечно).

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

Характеристики движения наблюдаемой цели можно измерить дополнительно: да, какую-то информацию даёт доплеровский сдвиг, но доплеровский эффект и так используется при синтезировании, так что возможности не так уж велики. Однако никто не запрещает определять базовые параметры движения при помощи дополнительных сигналов, а в случае достаточно продвинутых РЛС – пытаться вычислительно оптимизировать сигнал, фактически, перебирая разные варианты в поисках минимальных расхождений между базовыми точками, которые, для того же объекта, наблюдаются вспомогательными приёмниками. Можно также использовать сигнал от подстилающей поверхности в качестве опорного, вычисляя разность “от фона”. Так как наблюдаемый объект, в подавляющем большинстве случаев, и достаточно жёсткий (то есть, “хвост” не изгибается до “носа”), и несравнимо больше длины электромагнитной волны зондирующего излучения (типичная длина волны здесь – это сантиметры), то определять характеристики движения можно точно даже без высокого разрешения по углу. Почему – без? Потому что именно получение высого углового разрешения в рамках изображения одного объекта и является конечной целью обратного синтезирования апертуры: получив “картинку” с характерным силуэтом можно автоматически распознать тип наблюдаемого объекта.

Пишут (англ.), что Google собирается для всех разработчиков приложений под Android на google-сертифицированных устройствах потребовать регистрацию аккаунта и регистрацию ключей подписи. Регистрация, конечно, должна быть в корпорации Google. Иначе приложения невозможно будет устанавливать (механизм реализации запрета пока не описан, но это ведь детали). Разработчик должен регистрироваться и получать разрешение даже в том случае, если приложение не распространяется через Google Play, а публикуется каким-то сторонним сервисом. Фактически, всё идет к тому, что самостоятельно разработанное приложение нельзя будет без регистрации аккаунта разработчика установить на самостоятельно же приобретённое устройство (такое вот очередное подтверждение того, что “собственный” смартфон вовсе и не принадлежит, как система, купившему его пользователю).

Этого, конечно, следовало ожидать: эффективны именно ограничения по конкретным источникам исходного приложения, а не по “витринам-магазинам” (к которым относится и Google Play). “Витрины-магазины” можно обойти, как-то ещё раздавать код, другими способами. Но если в процессе подтверждения подпись от ключа разработчика проверяется всегда относительно некоторого центра доверия, встроенного в систему, то уже нет разницы, откуда взят сам код приложения.

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

В статье Ars Technica (по ссылке выше) пишут, что Google, якобы, не планирует проверять само приложение (как в случае с Google Play). Но это вряд ли, что оно так будет. По крайней мере, в сопроводительных документах Google написано, что для бесплатных аккаунтов введут ограничения и по количеству приложений, и по количеству установок. Дело в том, что, технически, цифровой подписью всегда подписывается конкретная сборка (нельзя подписать произвольный идентификатор, который автоматически привяжется ко всем возможным вариантам – такого не предусмотрено). Поэтому и провайдер системного сервиса проверки вполне может регистрировать в центральном репозитории тоже только конкретные сборки, по отпечатку. А это эквивалентно проверке кода приложения: по результатам – можно отключить и аккаунт, и сами приложения удалить с пользовательских устройств.

Я использую для чтения RSS полезный инструмент Tiny Tiny RSS, который работает в контейнере на внешнем сервере. И вот с некоторых пор пропал с этого сервера доступ к feeds.feedburner.com: где-то кто-то заблокировал, похоже. Из иностранных сетей доступ есть, но упомянутый сервер в российской сети, с российским IP. Проблема тут в том, что на feedburner.com “редиректит” трансляции своих корпоративных блогов Google. Непонятно зачем. А так как нынче в интернетах блокируют со всех сторон, то сразу и не скажешь – где именно оно закрыто, но возможно, что это для российских IP на стороне feedburner.com (который тоже Google, так что ничего удивительного, если так).

(Update, 28/08/2025: похоже, всё же, что вряд ли именно это – блокировка на стороне Google, по географической принадлежности IP: потому что из других россиских сетей доступ есть. Детали выяснить так и не удалось.)

С этими ИИ-LLM, “которые заменят всё и вся”, сейчас больше всего не радуют следущие моменты.

1.

Обилие сгенерированных ИИ-моделями картинок-иллюстраций на отдельных веб-страницах и на веб-сайтах вообще. Используются не только тематические ИИ-иллюстрации, но и различные фоновые изображения. Такие картинки однообразны. Обычно, содержат выраженные, и при этом одинаковые, “абсурдные элементы”: это и общая “механическая” композиция, и способ обособления “смысловых” элементов примитивным противопоставлением, крикливое оформление опорных объектов цветом, резкими углами и контурами.

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

Всё то же самое можно сказать и про сгенерированные видео, которые так же заполонили веб. Эти видеофрагменты, – особенно, сгенерированные “по фотографии”, – ужасны в своей визуальной тягучести и банальной бестолковости, но их постоянно приводят в качестве примеров типа “как было” (да!), ” как могло бы быть”.

2.

Большое количество явно сгенерированных LLM текстов, которые выдают за “оригинальные тематические статьи” – с примерами кода (неверного), с “математическими” утверждениями, очевидно абсурдными, но записанными при помощи терминов из техничного языка (сам техничный язык – не наследуется).

Как ни странно, но тексты, сгенерированные современными продвинутыми LLM, нередко узнать даже проще, чем результаты работы старинных “генераторов рефератов”: это связано с тем, что современные LLM выдают в тексте структуры “большего объёма” – оформление, построение блоков текста, все эти навязчивые, регулярные разбивки на “Почему {подставить описание}” – следует три описания “причин”, с обязательным оформлением в виде списка и “типографским” выделением фрагментов. При этом тексты написаны неплохим языком, но содержат фактические выдумки – даже не ошибки (“Not even wrong!”). Старые “генераторы рефератов” выдавали менее структурированный мусор, который больше похож на неудачный, но подлинный текст, написанный не слишком подготовленным человеком.

Однако далеко не все тексты, выданные LLM, легко и сразу опознаются: из-за того, что всё тщательно оформлено и структурировано, из-за того, что набор слов отлично мимикрирует под большие структуры подлинных текстов, часто приходится буквально продираться сквозь туман из токенов, чтобы увидеть бессмыслицу. О том же самом эффекте, например, писал разарбочик curl Стенберг, но уже применительно к сообщениям о несуществующих уязвимостях. Разбор этой “высшей чепухи” отнимает время. Но таких сгенерированных публикаций в вебе (и не только) становится всё больше и больше. Видимо, это и есть те самые триллионы строк кода (пример, к сожалению, – ресурс “Хабр”).

3.

Выдачу LLM нередко предлагают рассмотреть детально, а потом объяснить, почему же конкретно эта выдача не сработала или что там (конкретно!) неправильно. Но не всегда можно дать конкретный ответ про сгенерированный текст! То есть, генератор текстов выдаёт поток бессмыслицы, который настолько хорошо оформлен, что даже продвинутый читатель воспринимает этот поток на уровне “ну, может, я чего-то не понимаю, а тут-то всё верно написано”. После чего переправляет результат специалисту по той теме, которая затронута в сгенерированном тексте, а специалист вынужден это и читать, и объяснять, что там не так примерно всё, кроме грамматики (при этом объяснять-то нужно уже на более простом уровне).

Более того, бывает, предлагается подкорректировать и исправить ошибки в тексте, сгенерированном LLM. Смысл данного действия, что называется, тёмен – зачем пересылать текст от LLM? Запрос-то в LLM-сервис составить мог бы и сам будущий редактор этого текста. Хуже всего, что для многих и многих простых, но вполне практических, случаев LLM выдаёт подходящий текст, а всякие ложные предложения вылезают достаточно внезапно. Из-за того, что есть “примеры правильной выдачи”, нужно тратить время на то, чтобы доказать, что это сгенерированный бред, пусть и записанный наукообразно.

Причём, апологеты LLM-сервисов нынче специально объясняют с высоких трибун, что, якобы, у LLM-то всё правильно, так как эта LLM знает больше любого человека, а вот человеку сложно, – даже невозможно, – понять, что тут и почему “верно написано” LLM.

И это вот одна из явных угроз ИИ: в какой-то момент скажут, что всякая выдача LLM является верной, и даже уточнять эту выдачу может только другая LLM, но не человек, который, как давно написано в газетах, “ничего понять не сможет”.

В публикации на Ars Technica сокрушаются, что Китай, мол, начал интенсивно выводить на околоземную орбиту спутники своей новой сети. И сеть эта – “не просто другая версия Starlink”, но имеет потенциальные приложения для наблюдения за целями на земле и в воздухе, а вот в Штатах всё ещё не готова военная низкорбитальная сеть нового поколения (MILNET), да аналогичного назначения (которое, в отличие от китайской системы, тут прямо декларируется через СМИ).

Вообще, немного странно с уверенностью утверждать, что китайская сеть – это “не версия Starlink”. Возможно, это не версия официального описания предназначения Starlink – типа, спутниковая система только для цифровой связи, для доступа к Интернету. Но кто сказал, что Starlink так же не имеет “дополнительных функций”? Никто не сказал. Зато говорили прямо обратное: и про технологическую ветку Starshield и про то, что SpaceX выводит системы, действующие в интересах NRO (это штатовское агентство технической, – в основном, космической, – разведки). Так что Starlink вполне себе может быть сильно впереди по секретным составляющим. Такой вариант, кстати, неплохо объясняет и то, почему в Штатах переносят сроки развёртывания новых слоёв систем мониторинга на базе сетей спутников – они уже есть, но на другой базе. Заметьте, что потребителям “специальных данных” даже не обязательно знать, что их приносит сеть Starlink (в том числе, наземные терминалы).

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

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

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

Утверждение, что “квантовые компьютеры” уже превосходят классические по возможностям вычислений нынче превратилось в штамп. При этом, исходное рассуждение, стоящее за идей “квантовых вычислений”, вообще-то, обратное: можно ли из наблюдаемой на практике сложности вычислительного моделирования сделать вывод о возможности разработки более быстрых, квантовых, аналоговых вычислителей? Это до сих пор не подтверждено, а из того, что конкретный способ вычислительного моделирования некоторых физических процессов работает очень медленно, по сравнению со скоростью моделируемого процесса, вовсе не следует необходимость наличия новых, превосходящих вычислительных возможностей за этими моделируемыми процессами.

Действительно, попытки точного моделирования определённых физических процессов на “пошаговых” компьютерах (классических) приводят к экспоненциальному росту вычислительной сложности. Конечно, сложность моделирования зависит от используемых алгоритмов. Тем не менее, в реальном эксперименте эти моделируемые физические процессы происходят очень быстро. Как бы, им не мешает экспоненциальная вычислительная сложность модели. Более того, в случае квантовых экспериментов, к которым относятся “квантовые компьютеры”, распределение вероятностей возможных результатов с хорошей точностью предсказывает аппарат квантовой механики, а расчёт этого предсказания – вовсе и не требует экспоненциально сложных вычислений.

Да, поскольку моделирование “квантовых вычислений”, проводимое типовыми методами классического компьютера, оказывается экспоненциально сложным, то, получается, имеющиеся возможности моделирования отстают от физического эксперимента. Но даёт ли это гарантии вычислительного превосходства? Нет.

Медленное моделирование, само по себе, это медленное моделирование, а не доказательство превосходства “квантовых вычислений”. Более того, пока что даже для случаев мнимого “превосходства” на специально подобранных задачах – появляются улучшенные методы быстрого (не “экспоненциального”) классического моделирования. Это именно что специальные алгоритмы для “некоторых типов задач”.

Но, всё же, нетрудно найти и конкретные примеры, когда возможности физического эксперимента по быстрому завершению процесса превосходят возможности классических компьютеров по моделированию исхода этого же эксперимента. У Ричарда Борчердса есть прекрасная иллюстрация (YouTube, англ.): квантовые вычисления на фарфоровом чайнике. Фарфоровый чайник, упавший на бетонный пол, разбивается существенно быстрее, чем суперкомпьютер успевает предсказать конфигурацию осколков чайника. Но только лишь из этого наблюдения – не следует обратное: что, мол, можно подключиться к сверхмощному вычислителю внутри чайника, чтобы использовать его для решения других задач.

Практические вычисления подразумевают и управление процессом, и получение полезного результата, а не только квантового шума (не путать с хайпом), чтобы с ним бороться “методами коррекции ошибок”. То есть, из практической сложности некоторого классического моделирования вовсе и не следует, что конфигурация исходного физического эксперимента гарантированно обращается – мол, можно извлечь “вычислительную мощность”.

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

Предположим, что речь идёт о симуляции вселенных, а расчёт конфигурации осколков разбитого чайника проводит некий гипервизор, реализующий симуляцию. Пока конфигурация осколков не определена, чайник не разбивается. Но этого, очевидно, обитатели симуляции не могут обнаружить – в коде не предусмотрено веток с зависанием чайника: из-за одного чайника зависает вся симуляция вокруг. Да-да, тут сразу напрашиваются эффекты склеек: что же, через некоторое время, будут видеть те обитатели, которые оказались за пределами “сектора зависшего чайника”? Вспоминаем принцип относительности Галилея и то, что в физике вокруг него. Но это уже детали, которые могут наблюдаться при помощи телескопов, а могут и нет. Главное, что если осколки чайника обсчитываются вселенским гипервизором, то, конечно, можно и нужно попробовать навязать этому гипервизору дополнительные вычисления: не то чтобы это совсем уж здравая, – в психическом, так сказать, смысле, – идея, но точно богатое теоретическое направление.

Такие вычисления могли бы выполняться быстрее, чем на суперкомпьютере в той же симуляции, поскольку суперкомпьютер обсчитывается более медленными фрагментами кода на стороне гипервизора. Почему это так? Потому что суперкомпьютер построен из отдельно моделируемых кусочков – транзисторов внутри симуляции и тому подобных элементов. Реализация каждого элемента требует ресурсов. Это как модель компьютера на “редстоун-релюшках” в Minecraft: работает, но очень медленно. А вот вычисление конфигурации осколков чайника – вселенский гипервизор реализует непосредственно, на своей аппаратуре. Могли бы это и быть “квантовые вычисления”? Да, вполне.

Вот только задача навязывания вселенскому гипервизору вычислений, во-первых, это “совсем другая история”; во-вторых, всё равно далеко не факт, что результат таких вычислений удастся простым способом спустить из гипервизора в конкретную симуляцию. Спуск может сопровождаться тем самым необратимым зашумлением, которое и обозначают “декогеренцией” и прочими забавными терминами. Мало просто выйти из “песочницы” симуляции – нужно так выйти, чтобы осталась возможность спускать результат тем процессам, которые всё ещё в песочнице. Теоретически, в такой модели, спуск – это и есть коррекция ошибок квантовых вычислителей. Которая коррекция, – внезапно! – тоже требует вычислительных ресурсов.

В общем, из сложностей конкретного вычислительного моделирования не следует наличие новых, превосходящих вычислительных возможностей “на той стороне”. То есть, если ваша модель медленная, это не означает, что моделируемый процесс именно обсчитывает сам себя быстрее – нужно доказать и то, что невозможно предложить более быстрый алгоритм с данными ограничениями, и то, что за моделируемым процессом тоже стоят вычисления, но на “другой аппаратуре” (“гипервизор”). Хорошие новости: если описанное вычислительное преимущество всё же есть, всё же оно скрывается за реализацией быстрого физического эксперимента, то классическое моделирование, действительно, всегда будет медленнее, как в случае с вселенским гипервизором выше.

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

(Это версия статьи, которую я вчера разместил на “Хабре”.)

Пишут про очередной фишинг с “омоглифом” в доменном имени. Там даже не просто омоглиф, а “омоглиф-лигатура”: то есть, символ, не входящий в обычный DNS-набор, подменяет сразу и косую черту, и “букву”, что позволяет построить имитацию URL в зоне booking.com (но зона там другая). Это, к сожалению, всё давно известные эффекты желания использовать Unicode там, где использовать Unicode не нужно. Я ещё в 2009 году описывал принцип построения таких фишинговых ссылок, и в той же записке привёл полностью рабочий пример с именем, имитирующим домен “проверка.рф” в зоне .РФ (самого .РФ тогда ещё не было в корневой зоне). Вообще, браузеры и другие клиенты должны выводить DNS-лейблы, записанные смешанными алфавитами, только в Punycode, латиницей, но, впрочем, это тоже полумера.

Современное объединение вычислительных IP-сетей, ранее известное как “Интернет”, обладает интересными особенностями, которые прямо связаны с практической трактовкой термина “сетевая прозрачность” разработчиками приложений.

Например, ранее такой разработчик мог успешно использовать абстракцию TCP-сокета: если установлено соединение с некоторым удалённым узлом через такой абстрактный сокет, то просто пишем в сокет байты данных, предназначенные удалённому узлу, а читаем – данные, которые тот узел прислал. На этом “дуплексном” потоке можно строить прикладной протокол, реализующий уже сервис для конкретной задачи – например, отправку потокового видео, или какой-нибудь телеметрии. Сам этот верхнеуровневый протокол тут не важен. Важно, что подлежащий TCP-сокет рассматривается как транспорт с “сетевой прозрачностью” – то есть, этот сокет одинаково прозрачен для разных верхнеуровневых протоколов. Однако сейчас это уже далеко не всегда так: глобальная Сеть, если наблюдать с точки зрения описанных сокетов, оказывается непрозрачной именно для разных протоколов, которые уровнем выше сокета. Одна телеметрия проходит, а другая – уже нет. Какой-то протокол работает только в одну сторону. Но транспортный сокет (пусть, TCP) открыт один и тот же.

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

Теперь не просто уровни перемешиваются (я как-то про это писал отдельно), но особенности, проявляющиеся в результате анализа поведения сети за сокетом, на низком уровне, просачиваются на уровень верхний, который ранее считался “абстрактным”.

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

Опубликовал на “Хабре” статью по теме занимательной арифметики и вычисления периода записи дробной части чисел в позиционных системах счисления. Это, фактически, развёрнутое объяснение того, почему можно на калькуляторе проверить период записи рационального числа 1/(7^11) – тут важно, что это объяснение “почему”, и на примере двоичной системы счисления (думаю, что это по теме подходит на “Хабр” хорошо), а иначе-то всю вторую часть можно сильно сократить, определив период для 1/7. Сам исходный период, для 1/(7^11), я привожу в пример в статье про шумеро-вавилонские цифры.

В мае этого года я писал, что о потенциальном требовании встроить в чипы GPU аппаратную геолокацию и возможность дистанционного отключения “меньше шумят, чем про требования “официальных бекдоров” в системах обмена сообщениями на смартфонах”. Но вот на днях хотя бы в корпоративном блоге NVIDIA опубликовали сообщение (англ.) о том, что “бэкдоры это плохо”, а аппаратные бэкдоры “от разработчика” – ещё хуже. Поэтому, как пишут, бэкдоров никогда не должно быть в чипах NVIDIA (про смартфоны, кстати, тоже упоминают, как и про типовой для этой темы случай Clipper Chip).

Насколько подобные дежурные утверждения, – опубликованные, видимо, в качестве ответа на волну в СМИ, – будут соответствовать непростой реальности – это ещё нужно посмотреть, конечно.