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

Кто-то опубликовал черновик (draft) с описанием IPv8, очевидно, сгенерированный при помощи LLM: там во первых же строках предлагается аутентификация узлов с OAuth2, JWT-токенами, “из локального кеша”, и валидация каждого интернет-пакета через специальный DNS8 – дальше же можно не читать черновик, не тратить время. Печально, но теперь пишут на профильных сайтах, что это “организация IETF” выставила “черновик новой версии протокола IP”. Однако на странице данного черновика прямо, на специальной плашке, написано, что IETF никак данный черновик не поддерживает: “This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process”. Что, конечно, не удивительно: потому что не требуется одобрение и поддержка IETF для публикации черновика – кто угодно может опубликовать черновик.

Решил посмотреть, как Google переиндексирует ссылки с dxdt.ru на dxdt.blog – попутно наткнулся на ИИ-выдачу, в которой попалась забавная интерпретация названия одной из тем сайта.

На Dxdt есть категория “О рениксе”, к которой я отношу заметки, рассказывающие о проявлениях разной чепухи – что, в общем, не удивительно: слово “реникса” – это из пьесы Чехова, где оно возникает в анекдоте про неверное прочтение слова “чепуха”, записанного курсивом. И действительно: кириллическая строчная “ч”, рукописным курсивом, выглядит как курсивная же латинская “r”. Unicode, к сожалению, воспроизвести не позволяет. Хоть соответствующий символ там и имеется – Mathematical Script Small R, – но вот в шрифтах он, обычно, выглядит как “правая” “рукописная” r: 𝓇.

В общем, Unicode – юникодом, но исходное русское “чепуха” в анекдоте из пьесы Чехова выглядит как “renyxa”, то есть, “реникса”, если читать на латыни, хоть такого латинского слова и нет. Ну, как нет – тут-то система Google LLM для поиска (разновидность Gemini?) слово “подходящее” нашла, написала, что “О рениксе” происходит от латинского renixus, которое есть вариант renisus – “сопротивляющийся”. Мол, тут игра слов: с одной стороны – “чепуха”, а с другой – реальное латинское слово. Так-то.

Чуть более года назад известная компания по продвижению ИИ – Anthropic – заявляла, силами своего генерального директора (CEO), что “через год 100% кода будет писать ИИ/LLM” (это цитата, по ссылке есть видео). Год прошёл. Не похоже, что доля программного кода, генерируемого ИИ, даже приблизилась к 100%. Несмотря на весь “хайп”, несмотря на “дефективность” самого показателя – “количество написанного кода”. Процитирую свою заметку, опубликованную в марте прошлого года:

“Проценты сгенерированного программного кода” – очень занимательный показатель. И не так важно, в чём его взвешивать – в строках или килобайтах командных слов. Например, можно генерировать “тавтологические строки”, которые компилятор будет просто выкидывать: if(a == b){a = b}…; или for i in [0,100]: b = 10; и т.д. Какая доля таких строк может быть в тексте программы? Сколь угодно близкая к 100% – чтобы программа хоть что-то делала, конечно, придётся написать пару вызовов, условно, каких-нибудь print “Hello!”. Заметьте, что даже корректную реализацию всякого алгоритма на ЯВУ нетрудно растянуть по “строкам кода”, что уж говорить про некорректные реализации.

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

У меня есть очень старый аккаунт Google Apps “для домена” – ещё со времён бета-тестирования, бесплатный (каким-то чудом). Вот я настраивал там TOTP, поскольку Google перестал пускать без “второго фактора” (очередной маркетинговый трюк), и обнаружил, что в панели администратора теперь есть специальный раздел “Углеродный след” (Carbon Footprint for Google Workspace). Кто бы мог подумать.

Кстати, вот ещё из очевидного “творчества” ИИ/LLM – попалось на “Хабре” (где, похоже, результатов генерации LLM, – “ИИ-помоев”, – только становится больше), дословная цитата:

“TXT-запись — это произвольная строка текста привязанная к домену. Придумали её для SPF (верификация почтовых серверов) и DKIM, потом стали использовать для подтверждения владения доменом в Google Search Console и Let’s Encrypt.”

На минуточку: TXT-записи – описаны в RFC 1035, это 1987 год, однако сама концепция размещения TXT-записей – ещё старше. Никакого SPF, – а тем более, DKIM, – тогда ещё не было, и никто не придумывал TXT-записи для SPF и DKIM.

SPF (эта технология оформилась в начале 2000-х годов, TXT-записи уже были) – вообще первоначально использовала отдельный специальный тип DNS-записи (SPF-запись), который сейчас отнесён к устаревшим, а данные SPF, действительно, сейчас размещаются в TXT-записях, но из этого не следует, что TXT-записи “придумывали для SPF”. DKIM – та же история, только ещё более свежая, из 2007-2011 (исходный документ RFC 4870 – это 2007 год, но данный RFC сейчас имеет статус “исторического” и не применяется).

Ну и забавно выглядит утверждение, что “потом стали использовать для подтверждения владения доменом” – то есть, вообще не верно: подтверждение с помощью TXT-записи применялось раньше и независимо от SPF/DKIM.

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

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

Это ChatGPT современной версии (которая доступна через веб-интерфейс на бесплатном аккаунте, видимо, какая-то 5.x). Попробовал старинный запрос – нарисовать настенные часы. Но в этот раз – с 11-часовым циферблатом (такие картинки полезны, когда нужно объяснить арифметику остатков, например, сравнивая составное 12 и простое 11). Пишем достаточно подробный, на мой взгляд, промпт на русском (специально):

“Нарисуй настенные часы с 11-часовым циферблатом, которые показывают без двадцати десять”.

Казалось бы, прошло уже несколько лет “улучшений” и хайп только набирает обороты, но, к сожалению, результат, как обычно, не слишком-то полезный – см. ниже.

(Здесь двенадцать часовых отметок, но две обозначены символом “11”, да и стрелки показывают не 9:40.)

В копилку примеров реального использования ИИ/LLM.

Попробовал тут выяснить, можно ли через ChatGPT узнать о группах для протокола FFDH (“мультипликативного” Диффи-Хеллмана, DH), используемых в TLS 1.3. Довольно специальный вопрос. Но зато вполне конкретный. Удивительно, но ChatGPT 5.2 тут же верно сообщило и номер RFC, где описаны эти группы, – RFC 7919, – и о том, что группы строго зафиксированы, что их всего пять. Это всё верно. Но, как обычно в таких делах, не будем торопиться с выводами.

То есть, подразумеваем, что ChatGPT тут использует человек, хорошо знакомый с математической частью, но который хочет узнать технические детали DH конкретно в TLS 1.3. Первая выдача ChatGPT, пусть и содержала какие-то домыслы про HSM и пр., но оказалась бы в таком сценарии полезной: номер RFC, информация о том, что используется зафиксированный набор групп, в общем – по теме и неплохо. В этом-то и кроется ловушка, как будет видно далее: данная система легко, с первого шага, производит впечатление “информированной”, но таковой не является.

Следующим запросом я попробовал выяснить значение конкретного модуля конкретной группы (основной параметр, задающий группу для FFDH, – простое число, называемое модулем). Опять же, удивительно, но ChatGPT даже смогло “понять” и корректно обработать опечатку в моём запросе: я пропустил одну цифру, написав ffdhe372 вместо ffdhe3072.

“В TLS нет группы под названием ffdhe372” – верно сообщило ChatGPT (здесь и далее я перевожу с исходного английского). “Вы наверняка имели в виду ffdhe3072 (RFC 7919, Group 15)” – уточнило ChatGPT. Что это за “Group 15” – непонятно, но, ладно, в остальном – очень верно. Именно ffdhe3072 и имелась в виду. Опять же, выглядит, как ответ очень “информированной” системы. Не то чтобы исправление подобных опечаток с использованием статистики корпуса текстов представляло какую-то техническую трудность, но, тем не менее, создаёт впечатление “подлинности”.

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

Нет. Всё не так, несмотря на непрерывное маркетинговое давление.

Дальше я спросил, как доказывается, что это – простое число. (Модуль должен быть простым числом, это базовое требование.) И тут ChatGPT кинулось в рассказы о тестах на простоту, о “доказуемо простых” числах и т.д., заявив, что использовался “алгоритм Маурера” (Maurer) и написав тому подобные техничные слова. Проблема в том, что это всё общие методы, не имеющие отношения к конкретному RFC и к конкретному модулю.

То есть, ChatGPT заявило, что простые модули в RFC 7919 выбирались методом Маурера (или по алгоритму, это не важно), начиная с некоторого небольшого известного простого. Это совсем не верно, но звучит очень похоже на правду, если только вы уже не знаете технических деталей. Такой вот ловкий обман. Естественно, тут же ChatGPT добавило показательный, по своему ложному положению, текст: “если бы в TLS использовались простые числа, похожие на случайные, но без доказательств, то злонамеренная сторона-генератор могла бы встроить бэкдор”. Этот фрагмент дословно верный, но только если его рассматривать вне контекста обсуждения и исходного запроса. А если в контексте, то под “доказательствами” тут имеются в виду “сертификаты” (“свидетели”) простоты числа, и это не имеет отношения к методу “защиты от бэкдоров”, который должен быть направлен на исключение возможности получения числа специального вида – доказательства тут должны доказывать то, что алгоритм не позволяет выбрать произвольное простое число, а числа там всегда простые. (Да, математически, наличие “сертификатов”, доказывающих простоту, – вычислительно ограничивает возможности по свободной генерации простых, но тут речь точно не об этом, да и ограничения там не являются блокирующими.)

Итак, следующий мой вопрос был о том, как же именно был получен модуль ffdhe3072.

Метод вычисления всех модулей из RFC 7919 описан в самом этом RFC. Буквально. Я как-то даже писал об этом подробно. В основе вычисления – запись числа e. В этом весь смысл: числа взяты “из записи” e, а не придуманы “с бэкдорами”. Схема называется NUMS – Nothing Up My Sleeve (“ничего в моём рукаве”).

То есть, если бы в ChatGPT был интеллект, – пусть и искусственный, – то этот “интеллект” взял бы RFC и прочитал. Тем более, что так хорошо всё начиналось. Но нет. ChatGPT стало продолжать в красках расписывать, что модули для RFC 7919 были получены по “детерминированному алгоритму Маурера”, прямо приводя фальшивый способ получения исходной константы: seed = SHA-256(“TLS FFDHE 3072”). Да. Настолько детально. И так далее, и тому подобное. Никакого отношения к RFC и к оригинальному источнику значений модулей – в этом не было (в RFC, ещё раз, написана конкретная формула, но она вообще не имеет отношения к “Мауреру”).

Это очередной пример большой проблемы: данные системы AI/LLM генерируют огромное количество текста с глубокими фактическими ошибками; на это тратится много энергии в дата-центрах; результат – затапливает; результат – уже встраивают не только в программный код реально используемых систем, но и в те же RFC. Если вы не специалист, который уже в деталях знает то, что пытается “выяснить” через LLM, то шанс обнаружить дефект и подмену минимальными усилиями – совсем не велик: требуется потратить много сил и времени.

P.S. А число, полученное как SHA-256(“TLS FFDHE 3072”), – составное: 0xd73d45623a7a52d11ea654956e701554a137fafd3545d46379891d7c4c79f545 = 3^2 * 7 * 3719447821 * 27939151181 * 3616471485699239 * 4111907187916820252669152053322571860357.

Из Ars Technica отозвали статью (англ.) про AI-бота, из-за наличия в той статье поддельных цитат, сгенерированных другим AI/LLM-ботом.

Уровень даже технической журналистики, к сожалению, продолжает падать. Хотя – казалось бы. Но нет, при поддержке LLM – ускорить падение уровня нетрудно. Естественно, написано, что редакционная политика Ars Technica запрещает использование текстов, сгенерированных ИИ/LLM, кроме как в качестве примеров того, что может сгенерировать LLM. Это не помогло.

На сайте Gramota.ru опубликовали “слова 2025 года”, что бы это ни значило, и слово-победитель в области “Информационных технологий” – “вайбкодинг”.

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

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

(Ссылка выше – ведёт на страницу без разметки стилей, но так сделано на сайте; возможно, тоже “вайбкодинг”; как сослаться на нормальную страницу за 2025 год – непонятно.)

Очередное хайп-продолжение со стороны компаний, продвигающих ИИ/LLM в разработке программного кода. Пишут (англ.), что Anthropic нынче заявляет о написании “с нуля” на Rust компилятора C, всё силами “шестнадцати ИИ-агентов”. Компилятор – во много десятков тысяч строк кода. Вообще, как это нужно понимать, если выкинуть хайп-составляющую?

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

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

А компилятор для подмножества C, – с куда меньшими оговорками, чем в случае ИИ/LLM выше, – можно уложить в 512 байтов, если что. И даже без Rust. Вот только с хайпом в СМИ на этом направлении будет сложновато.

Пишут, что на такое мероприятие, как инаугурация мэра Нью-Йорка (США), запрещено приносить Flipper Zero и Raspberry Pi. Да. Прямо так и указано в списке запрещённых предметов, наряду с большими сумками, домашними животными (уровня pet, про буйволов ничего не сказано), велосипедами, креслами, битами и другими объектами, которые, прямо скажем, чуть более часто встречаются, чем Raspberry Pi и Flipper Zero. Вместе с тем, Arduino, получается, можно проносить. Уже проще.

Самое забавное, что смартфоны и ноутбуки – не запрещены. Сравните, как говорится, возможности Flipper Zero с возможностями ноутбука, к которому подключен набор решений на ESP32 и, предположим, HackRF (все разрешены).