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

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

Раньше секунду определяли асторономическими методами, на основе наблюдений вращения звёзд и Солнца вокруг Земли (тут нет ошибки: именно вокруг Земли). Этот вариант определения, фактически, базировался на предположении о точности и стабильности угловых измерений. В 1960 году от астрономического определения секунды отказались, как раз по причине непредсказуемых, – но наблюдаемых, – флуктуаций земного движения. Секунду привязали к атомным процессам.

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

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

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

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

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

С эталонными источниками частоты/времени связана одна большая проблема: как их синхронизировать между собой? Аппаратура, на которой ведут сверхточные подсчёты эталонной частоты, очень чувствительна. Настолько чувствительна, что для конкретной локации, в которой работают такие часы, требуется учитывать гравитационный потенциал, задающий локальную практическую систему отсчёта. Что уж там говорить про колебания почвы, вызванные проезжающим мимо трамваем. Для дистанционной синхронизации таких часов сейчас используют спутниковые радиосигналы, а также и опотоволоконные линии связи. Оптоволокно в чём-то даже лучше.

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

Секунду в стандарте собираются переопределять. Возможно, это сделают уже в 2030 году (популярная дата). И тут прямо учитываются возможности трансляции эталонной частоты другим участникам обмена временем: если точность передачи не превышает имеющееся определение секунды, то нет причин и для переопределения. Речь тут идёт о величинах порядка 10^(-18). А помимо точных методов синхронизации по оптоволокну, разрабатывают и специальные оптические часы-эталоны, которые можно физически перевозить с места на место, сохраняя высокую точность (очевидно, с коррекцией по траектории, в том числе, гравитационной).

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

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

В продолжение предыдущей записки, про решение задач с Международной олимпиады средствами LLM: самое забавное, что, например, решение для первой задачи ММО-2025, которое сгенерировала “экспериментальная модель”, почему-то содержит ответ в самом начале – то есть, буквально, написано: смысл решения – доказать, что правильный ответ – правильный. Вот этот фрагмент, в виде скриншота (потому что там нужно “рендерить” LaTeX и Markdown):

Далее там идёт очень большой и не очень внятный сгенерированный текст доказательства, перегруженный отступлениями, понимать который довольно сложно, но не потому, что задача сложная, а потому, что много лишнего в “рассуждениях”. Сомневаюсь, что полезно делать его полный разбор. (Нет, сама исходная задача не требует таких больших объёмов для записи решения.)

Небольшое техническое пояснение: первая задача IMO 2025 это комбинаторная геометрия, нужно посчитать возможные варианты покрытия целых точек на решётке прямыми – это один из самых популяных “сеттингов” для олимпиадных задач; соответственно, набор возможных вариантов – {0, 1, 3} – появляется в процессе решения, поскольку составляет основную содержательную часть этого решения: надо понять, что других чисел (это количество подходящих прямых) там не может появиться; и то, что отсутствует 2, это, вообще говоря, не самый тривиальный момент (но и не самый сложный). Так что то, что решение от LLM OpenAI построено на доказательстве верности состава ответа, без указания на то, как этот состав получен, – почему, хотя бы, там не {1, 2, 3}, – выглядит весьма странно.

Сообщают (осторожно, ссылка на Twitter), что некая “внутренняя”, экспериментальная модель от OpenAI продемонстрировала уровень “золотой медали” при решении задач Международной математической олимпиады (ММО) 2025 года. Подробностей, как обычно, нет, но опубликованы решения, которые сгенерировала та модель. Всё это занятно. Поделюсь ниже скриншотом по этой же теме, он из недавней выдачи “общедоступной” LLM той же корпорации – ChatGPT 4o.

“Нет, 205 не делится на 5” – считает данная LLM. Сам транскрипт относится к “обобщённой” задаче про набор воды вёдрами – там было три ведра огромного объёма и решать нужно было, понимая общие принципы обратимости/делимости. Откуда, собственно, и взялся НОД (gcd). Так что количество шагов и пр. – это более или менее близко к задаче, вот только использовать три ведра LLM не “догадалась”, без подсказки. Но это детали. Главное – это вывод про то, что “205 не делится на 5”.

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

Забавная история.

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

Слушать эфир можно как каким-то одним из имеющихся радиотрактов (WiFi, Bluetooth/BLE, GNSS, GSM и т.д.) или всеми сразу. Современные радиомодули очень чувствительные и избирательные. Если использовать непосредственно функции прошивки радиомодуля, то, вообще говоря, принимать можно далеко не только “логический WiFi”, но и разнообразные другие сигналы, в том числе, сигналы радаров, спутниковых передачиков (подтверждается Starlink) и т.д., и т.п. Да, приниматься могут быть гармоники побочных утечек, но для данной задачи это не важно. Если сомневаетесь, то вспомните историю появления такого направления, как RTL-SDR – там аппаратной основной вообще послужил бюджетный ТВ-тюнер. (Замечу, в скобках, что даже если в пользовательском интерфейсе смартфона указано, что соответствующие радиомодули “отключены”, это не означает, что они реально отключены – реально отключить можно было бы только в специальной архитектуре, аппаратной кнопкой, но таким практически никто не пользуется, да и кнопка не даёт полной гарантии.)

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

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

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

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

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

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

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

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

Во-первых, вот уже лет пять как начали присваивать статус “признанной уязвимости”, “с кодом CVE”, даже самым мелким обнаруженным дефектам, практическое значение которых при проведении атак довольно сомнительно.

Во-вторых, сейчас сам поиск уязвимостей стал настолько массовым, что, действительно, находить их стали больше, в том числе, существенных (это и капитан Очевидность подтверждает). Рост интереса исследователей – вот единственный параметр, о котором можно судить, косвенно, по количеству публикаций уязвимостей. Да, находят весьма и весьма существенные уязвимости, которым десять и более лет – внимание, вопрос: когда эти уязвимости преобразовались в угрозы, если преобразовались? В момент внесения в код, или когда об этом в газетах написали, десять лет спустя?

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

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

P.S. Пожалуй, тут нужно привести конкретный пример. Представьте, что у вас определена следующая внутренняя угроза: “Локальный непривилегированный пользователь через уязвимость библиотеки в системном сервисе повышает права своего аккаунта и удаляет все защищаемые данные”. Зависит ли определение (хотя бы описание) этой угрозы от того, что в утилите sudo найдена уязвимость, позволяющая поднять права до суперпользователя? Нет, не зависит, хоть в определении угрозы и используется слово “уязвимость” – рассматривать такую угрозу нужно даже в том случае, если sudo вообще нет в системе. Поэтому про sudo в определении угрозы ничего нет, определение не зависит от конкретных уязвимостей, так как они рассматриваются в самом общем смысле. Появилась ли эта угроза лишь после того, как опубликовали данные об уязвимости в sudo и демонстратор (PoC)? Нет, конечно – угроза была и раньше. Появление информации о новой уязвимости (плюс один к количеству индексов в базе сканера), тут никак не повлияло на количество угроз.

Cloudflare публикуют разбор причин аварии сервиса DNS-резолвера 1.1.1.1, который некоторое время был недоступен (глобально) 14 июля 2025 года. Краткая причина, как это нередко бывает, – некорректная работа с BGP: ошибочно удалили маршруты к сервису 1.1.1.1 (это, в принципе, было понятно практически сразу). Интересный момент: написано, что после аварийного отзыва штатных маршрутов Cloudflare – анонсировать префикс 1.1.1.0/24 начала AS4755 (Tata Communications India). Но отдельно отмечено, что этот “угон префикса” не был причиной недоступности сервиса. Всё равно – странно.

(Это существенно дополненная версия статьи, которую я недавно публиковал на “Хабре”. Дальше используются клинописные знаки из Unicode. Если в тексте на вашем устройстве клинопись не отображается, то это из-за отсутствия шрифтов; добавьте шрифты с клинописным блоком, cuneiform; например – Noto.)

На древних глиняных табличках из Месопотамии встречаются математические тексты с достаточно сложными вычислениями. Кроме прочего, для записи чисел использовалась шестидесятеричная система, которая имеет существенное «компьютерное» преимущество перед современной десятичной. Древняя шумеро-вавилонская система счисления это позиционная система по основанию шестьдесят: каждой позиции соответствует количество единиц, умноженное на степень 60, значения позиций – суммируются. Обычный способ. Шумеро-вавилонская клинописная цифра 42 выглядит так: 𒐏𒐖. И это именно цифра, которой может соответствовать и число 42, и 2520, и 151200 и так далее (всё в десятичной системе), по степеням 60. То есть, 42, как число, – это 42 единицы, для 60^0 (в нулевой степени). А десятичное 151200 – это 42 * 60^2. И так далее. Доли представляются по обратным степеням основания, например: 42 * 1/60, 42 * 1/(60^2) == 42 * 1/(3600).

Поскольку основание 60, то нужно 59 цифр. Откуда и цифра 42 (конечно, 42 тут – это условное обозначение, поэтому к нему даже можно не приписывать указание на десятичную систему).

В клинописной записи отдельных цифр вертикальные “палки” обозначают единицы, если их количество не превышает 9, а “галки” – обозначают десятки, что, впрочем, не делает систему десятеричной. Так, 𒐏𒐖 – это четыре “галки” и две “палки”, соответственно: 10 * 4 + 2 * 1. (Кстати, с какой стороны тут правильно писать количество знаков, а с какой – вес? Это ещё один пример того, что порядок записи важен, и логическая часть практически всегда некоммутативная.)

Вообще, древнейшние шумерские системы счисления использовали для записи цифр круги и “полуовалы” – примеры есть в отдельной записке. “Галки” и “палки” появились позднее, когда система стала логически стройнее.

(Очень древняя табличка. Credit: Metropolitan Museum of Art.)

На иллюстрации выше – пример таблички (3100–2900 B.C.) со знаками, соответствующими кругам и “полуовалам” по способу построения. Видимо, это учёт кувшинов и мехов – нарисованы рядом. Точная интерпретация значений цифр на самых древних табличках трудна, так как система ещё не имела строгой типизации: в самых древних шумерских вариантах интерпретация цифр зависела ещё и от того, что именно подсчитывается. Использовался ли знак для обозначения мер зерновых, для записи количества кувшинов масла или площади земельного надела – числовое значение могло быть разным. Это в точности современный Javascript, неявно преобразующий строку в числовой тип.

Что касается Javascript, то это эквивалентные операции. Не сомневайтесь. Многие неотъемлемые части информационных технологий очень древние. Предположим, неявное преобразование типов приводит ASCII-код записи “42” в значение целочисленного типа 42. Это означает, что последовательность байтов 0x3432, превращается в 0x2A. Но парой байтов были обозначены ASCII-символы! У древнейших шумер были бы, предположим, кувшины с пивом, а не ASCII-символы. Не удивительно, что эффект позднее исправлен (но не в Javascript).

Протоклинописных кругов и “полуовалов” всё ещё нет в стандартном Unicode. Но есть предложение по добавлению нужных символов.

На этой иллюстрации – фрагмент таблицы начертаний древних шумерских цифр, которые предлагается добавить в соответствующий блок Unicode. Из состава таблицы нетрудно сделать вывод, что композиций протоклинописных знаков, встречающихся на табличках, гораздо больше, чем простой круг и не менее простой “полуовал”. Ещё больше вариантов образуется в результате интерпретации исходной записи. Скорее всего, недостаток детализации и отсутствие арифметической строгости беспокоил и древних пользователей. Поэтому способ записи модифицировали, заменив круглые цифры на системы “галок” и “палок”. Получилась, так сказать, более привычная шестидесятеричная клинописная система. Способ записи стал стройнее, а шумеро-вавлионские цифры – стали более доступными для современного взгляда. Эта система более привычна и в смысле Unicode.

Шумеро-вавилонская система счисления имеет целый ряд особенностей. Например, способ записи не подразумевал явного обозначения степени конкретной позиции: сколько там весит единица – 60, 60^3 – всё определялось контекстом. Таким образом, это древнейшая система с плавающей точкой! И она на несколько тысяч лет старше всем привычных float, double, как и современных стандартов “плавающей точки” вообще. Впрочем, если в современных стандартах бывает два нуля, – вообще говоря, не равных друг другу, – то в шумеро-вавилонской системе настоящего нуля, как такового, вообще не было. В более поздних вариантах появился знак для заполнения пустых разрядов – пара диагональных клиньев, – но он использовался только для разрядов, находящихся между другими цифрами, а не для обозначения порядка вообще, то есть, не использовался на конце записи, как в случае 1000.

Выбор числа 60 в качестве основания имеет арифметическое обоснование. У шестидесятеричной системы большое преимущество, если сравнивать, например, с десятеричной, а тем более – с двоичной, восьмеричной и шестнадцатеричной. Всё потому, что число шестьдесят – “очень непростое”: 60 = (2 * 2) * 3 * 5. В результате, арифметика записи по основанию шестьдесят оказывается удобной для отображения долей целых – можно самые ходовые доли записать точно: 1/2, 1/3, 1/4, 1/5, 1/6, 1/10, 1/12, 1/15, 1/20, 1/30, ведь знаменатели здесь являются делителями 60. “Точная запись” же означает, что для обозначения не придётся использовать бесконечную запись, как 0.333(3) для 1/3 в десятеричном случае. О точности более подробно рассказано ниже. Прежде чем перейти к дробям, нужно получше разобраться с шумерскими клинописными цифрами.

Итак, цифрами служили комбинации клинописных знаков. Мы уже назвали их “галки” и “палки”, что соответствует их начертанию и в Unicode, и на табличках. 𒌋 – это “галка”, которая соответствует десяти единицам; 𒐕 – это “палка”, которая соответствует единице. Единицы в количестве менее десяти записывались в виде плотного набора “палок”: 𒐛 – это семь. 𒌋𒌋𒐗 – это цифра, которой, если считать цифры по порядку, соответствует число 23, записанное десятично. “23”, как цифра, – не обязательно обозначает число 23. “Галки” повторялись кратно десяти единицам: 𒌋𒌋 – двадцать. Группироваться наборы “галок” и “палок” могли произвольно, что может затруднить разбор. Мы будем использовать запись, когда единицы переходят на вторую “строку”, если их больше четырёх, а десятки – группируются вертикально: 𒐏𒐝 – это цифра 49. Можно считать, что число 49 это порядковый номер сорок девятой цифры.

Возьмём снова цифру 23: 𒌋𒌋𒐗. В зависимости от позиции и от контекста эта цифра может обозначать единицы, то есть нулевую степень основания (60^0 == 1), или единицы при 60^1, или единицы при 60^2 = 3600. Соответственно, 𒌋𒌋𒐗 (“23”) в позиции единиц – это число 23 в десятичной системе. 𒌋𒌋𒐗 в позиции 60^1 это 23 * 60 = 1380 (в десятичной). А для второй степени: 23 * 60^2 = 82800 (десятичная).

(Цифра 42)

На коллаже выше – клинописная цифра “42” шумеро-вавилонской системы счисления. Вверху – современная запись (Unicode + шрифт, поддерживающий клинопись). Ниже – два варианта записи той же цифры на табличках: P493016 (середина коллажа) и P257557 (внизу). Обе таблички датируются 1900-1600 B.C. При этом на нижней табличке использован способ группировки десятков в цифрах, который отличается и от варианта на табличке в центре, и от варианта Unicode. Но, думаю, теперь нетрудно догадаться, где там что.

Позиции в записи чисел разделялись пробелами, что не всегда однозначно, из-за того, что нуля не было. 𒐖 𒌋𒐗 это, например, 2*60^1 + 13 = 133. Почему “например”? Потому что это система с плавающей точкой. 𒐖 𒌋𒐗 с тем же успехом можно интерпретировать как 2 + 13/60. Здесь 13/60 = 13*(1/60) – это интерпретация 𒌋𒐗 как 13 “обратных” долей, по степени 60^1. То есть, плавающая точка переплывает вправо на одно знакоместо. Такой произвольный сдвиг точки очень удобен с точки зрения вычислений по таблицам значений, мы в этом убедимся на примерах далее. И если данная особенность сильно помогает при практических вычислениях, то она же мешает при считывании результата спустя всего лишь три-четыре тысячи лет.

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

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

Старинная шутка гласит, что типов людей всего 10 – одни уже знают двоичную систему счисления, а другие – ещё нет. Система счисления – это способ записи чисел. Разные системы хорошо подходят для разных целей. Так, двоичная система подходит не только для записи шуток (0b0010 == 2), но и служит неплохим математическим фундаментом “железячных” компьютерных вычислений: компьютеры, как известно, не считают, а переключают транзисторные “флип-флопы”. Успешная интерпретация таких переключений возможна только потому, что есть двоичная система счисления.

Использование систем счисления с разными основаниями является привычной практикой: кроме двоичной и десятичной, распространены восьмеричная и шестнадцатеричная. Восьмеричная система, конечно, встречается нынче реже, чем шестнадцатеричная, но всё равно постоянно присутствует рядом с вами, если вы сетевой инженер или разработчик системного ПО. Например, один из штатных способов записи IP-адреса, при вызове тех или иных утилит, использует восьмеричную систему, вот так: 010.010.010.010 – это будет 8.8.8.8 в привычной форме по основанию 10 (десять). Согласно древнему соглашению, октет IPv4-адреса, начинающийся с нуля, интерпретируется как записанный в восьмеричной системе. На глиняных табличках из Месопотамии об этом ничего не сказано, но, из-за базовых unix-библиотек, такое преобразование сейчас касается не только октетов.

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

В древние времена, когда компьютеры были редкими и очень большими, данные в память вводили вручную, нажимая кнопки-биты и перещёлкивая тумблер записи. Если ваш компьютер работал на байтовых ячейках, – то есть, в один октет, восемь бит, – то опытный оператор мог каждую шестнадцатеричную цифру заданного значения моментально “выкинуть” на четырёх пальцах руки: каждый палец – один бит. Если бит установлен, то и палец выставляется вперёд, для нажатия на кнопку системы набора. 0xF – четыре пальца. 0x8 – указательный или мезинец, в зависимости от того, “тупоконечные” у вас пальцы или “остроконечные”. Не в смысле формы, а в смысле того, с какой стороны старший бит байта в представлении вашего компьютера. И так далее – прочие варианты “распальцовок” читателю предлагается отработать самостоятельно. Нынче навык сей доступен разве что редкому динозавру-технарю, да и не так полезен, однако верная распальцовка всё ещё может быть эффективно использована в беседе с молодыми DevOps, для пущего их убеждения. Заметьте, что две руки – это байт, а большим пальцем можно ловко перещёлкнуть тумблер записи, перейдя к следующему адресу. Хотя, тумблеров на компьютерах больше нет.

Не факт, что старшинство указательного пальца, взятое по модулю “хиральности” (правой/левой руки), оказало влияние на развитие систем счисления. Но вполне возможно, что принцип счёта по трём фалангам каждого из четырёх пальцев при помощи пятого прямо связан с двенадцатеричными системами, которые мы здесь не рассматриваем. Впрочем, как раз 12 * 5 == 60.

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

Всякую позиционную систему счисления можно использовать для записи дробей: возьмём обратные степени основания {-1, -2, -3…} и станем записывать дробную часть, отделив её от целой каким-нибудь знаком. Точкой, например. Это уже было проделано выше. Для десяти – получаем всем привычные десятичные дроби: 0.4242. Точно так же будут работать и двоичная, и восьмеричная, и шестнадцатеричная система. Нет разницы. Только вот с записью долей таким способом возникнет сложность иного рода: запись окажется “бесконечной вправо” (ну, если записывать числа и расставлять веса справа налево; “бесконечная влево” запись – это p-адические числа, другая тема, пусть и неожиданно близкая).

Так, 16 – это 2^4. То есть, основание шестнадцатеричной системы, при всём богатстве выбора, какое-то слишком “простое”, и проблемы начнутся с нечётными знаменателями в долях вида a/b.

Например, 1/5 == 0x0.33(3) – всё в шестнадцатеричной системе, а тройка здесь – в периоде (обозначается скобками). “В периоде” – это значит, что развернутая запись никогда не окончится. Однако в десятичной записи 1/5 == 0.2 – и точка. “Периода” нет, запись терминируется тут же. И это одно и то же рациональное число – одна пятая.

Да, формально, и 0x0.33(3), благодаря возможности обозначить “периодические цифры”, это точная конечная запись для 1/5. Да, к 0.2, если уж быть максимально строгим, должен быть приписан бесконечный хвост нулей – 0.2(0), но его принято не указывать (да вообще мало кто помнит, что он там есть, но его не видно; как и про второе представление с бесконечно повторяющимися девятками, для десятичной системы). Это всё так по определению, а требуется по тем же причинам, по которым в десятеричной (десятичной) системе 0.9(9) == 1.

Казалось бы, сложно ли записать (3) как период? Всего лишь скобки. Однако проблема в том, что длина периодической части может быть произвольной, не обязательно лишь одна цифра повторяется.

Заметьте, что 0x0.3 * 0x5 == 0x0.F. Аналогично тому, как 0.3 * 3 == 0.9. Но почему в десятичной системе 1/5 = 0.2? Потому что 10 == 2*5. Соответственно, все числа, представимые в виде 2^n * 5^m, будут регулярными в десятичной системе: “обратные” к ним можно записать в виде конечной дроби. Шестнадцатеричная же система имеет основание 2^4, а число 5 нельзя представить в виде 2^n, отсюда и дробная часть в периоде.

По тем же причинам 1/7 = 0x0.249(249). Шестнадцатеричная система. Три цифры – период.

А вот для 1/(7^11) период шестнадцатеричной записи после запятой составит 847425747 цифр (цифры записи будут шестнадцатеричные, но их количество – записано в десятичной системе, проверьте на калькуляторе). Так что проблема точной записи, даже если позволяется вводить дополнительную структуру и указывать период в скобках, – остаётся. Кстати, поскольку в разложении 10 есть 2, то найти столь же иллюстративный обратный пример – число, которое “хорошо” представляется в шестнадцатеричной системе, но “плохо” в десятичной, – не выйдет.

Будем обозначать клинописные цифры десятичной записью соответствующего числа, разделять цифры будем запятой “,”, а точку-разделитель целой и дробной части (мантиссы) – обозначим точкой с запятой (“;”). Это общепринятый сейчас способ. Тогда 1/7 в шестидесятеричной шумеро-вавилонской системе это 0; 8,34,17(,8,34,17) или клинописью:
𒐜 𒌍𒐘 𒌋𒐛 𒐜 𒌍𒐘 𒌋𒐛… (тут цифры повторяются с периодом три).

А что ещё за “обратные” числа? Например, в десятеричной системе деление на два эквивалентно умножению на пять с последующим сдвигом десятичной точки. Элементарный пример: 7/2 = (7 * 5)/10 = 35/10 = 3.5. В шестидесятеричной системе основание делится не только на 2 и 5, но ещё и на 3, и в шестидесятеричной системе регулярные числа – это все те, которые представимы в виде 2^n * 3^l * 5^m. Здесь, как мы разобрались выше, много делителей – [1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60], – поэтому сдвиг плавающей точки предоставляет больше возможностей для практических вычислений по таблицам.

В древней шумеро-вавилонской практической арифметике деление одного числа на другое выполняется с помощью специальных таблиц, записанных на глиняных табличках. Чтобы найти отношение A/B, древний инженер-информатик берёт “таблицу обратных” и находит число, обратное к B. Обратите внимание, что это не совсем те привычные обратные по умножению, не совсем B^(-1) – обратное здесь берётся по основанию системы счисления. Так, в десятеричном примере выше (про деление 7/2), обратное к 2 – это 5. Почему? Потому что 5 * 2 = 10, то есть 2/10 при умножении на 5 дают единицу.

Снова вспомним, что у нас плавающая точка. Цифра 1 в нулевом разряде, если сдвинуть точку вправо на одну позицию, даст запись числа 10, на две позиции – 100, и т.д. Поэтому, определив обратное 5 в десятеричном примере, остаётся просто посмотреть в таблицу умножения для 5, найти там 5 * 7 == 35, выписать ответ и не забыть сдвинуть десятичную точку: 3.5. Так что именно плавающая точка позволяет нормировать имеющиеся числа, приводя их к удобной для вычислений форме записи. Шестидесятеричная система действует так же, но у неё больше возможностей для точных вычислений, чем у десятеричной. Умение работать с таблицами обратных и с таблицами умножения очень актуально, ведь в древней Месопотамии нет даже механических арифмометров (ну, скорее всего, их либо нет, либо они слишком дорого стоят). А вот глиняные таблички умножения и взятия обратных для шестидесятеричной системы – есть.

Разделим 10,30 на 1,15. Это уже шумерские цифры (см. нотацию выше). То есть, 10,30 == 630 в десятичной, а 1,15 == 75 в десятичной. Найдём обратный к 1,15 – это 48, потому что 1,15 * 48 == 1, а именно – 3600 в десятичной записи; выше мы разобрались, что в шумерской системе нет строгой разбивки по позициям, поэтому единица для 3600 соответствует позиции с весом 60^2. Найдём результат умножения 48 на 10,30. Это 8,24 (нуля у нас нет – не забывайте). Как получилось 8,24? Скорее всего, для шумерского инженера-информатика это табличный результат – то есть, он должен быть уже записан на глиняной табличке умножения. Если же не записан, то инженер-информатик быстро вычислит его в уме, поскольку хорошо владет шестидесятеричной системой.

Посудите сами: 30 – это половина от “единицы”, то есть, половина от основания системы, от 60. Соответственно, умножать на 30 просто – работает так же, как умножение на 5 в десятеричной системе: умножаем на 1 и берём половину. Но 1, конечно, это 60 в десятеричной. То есть, нужно взять половину от значения цифры 48 – записываем цифру 24, всё в соответствии с таблицей умножения. И не забываем, что позиция плавающей точки только что сдвинулась вправо, ведь при умножении 48 на единицу, мы взяли эту единицу в позиции с весом 60, но исходная цифра 48 – это количество единиц в позиции с весом тоже единица (60^0). Естественно, если корректно отслеживать положение плавающей точки, то метод работает для любой позиции цифры 48. Так что – обычное быстрое умножение, сдвигами.

Теперь цифра 10 из 10,30. 10 – это одна шестая от основания системы, тоже удобно. Умножаем на единицу и берём одну шестую. Одна шестая от 48 – это 8. Поэтому и цифра будет 8, но она должна стоять в правильной позиции – то есть, на одну позицию левее. Перенос плавающей точки здесь соответствует “переносу единиц” в привычном умножении столбиком в десятеричной системе, но из-за большого количества делителей основания системы 60, схема оказывается более эффективной.

Итак, получили 8,24, в шумерских цифрах. Обратите внимание, что сейчас, после умножения “на обратный”, 8 находится в позиции с весом 60^2, а 24 – в позиции с весом 60. Поставим “плавующую точку” на место, сдвинув, как положено, на две позиции левее, и получим верный результат: 8; 24.

То же самое в клинописных цифрах, как это делал бы инженер-информатик в Месопотамии несколько тысяч лет назад, засечками на глине:

𒌋 𒌍 / 𒐕 𒌋𒐙 (здесь “слеш” – знак деления),

обратный: 𒐏𒐜, умножаем по таблице: 𒐏𒐜 * 𒌋 𒌍.

Результат: 𒐜 𒌋𒌋𒐘 – и через те самые несколько тысяч лет придётся догадываться, где же здесь стоит плавающая точка.

Всё это так хорошо работает потому, что 48 == 2^3 * 6, 10 == 2 * 5, 30 == 5 * 6 и т.д. Это всё регулярные числа, которые записываются точно в шеcтидесятеричной системе. Чуть выше мы нашли, что 1/7 в шумеро-вавилонской системе нельзя представить точно, потому что запись будет бесконечной: 𒐜 𒌍𒐘 𒌋𒐛 𒐜 𒌍𒐘 𒌋𒐛… Так происходит потому, что 7 – взаимно простое с основанием 60.

Знали ли об этом древние шумеры и вавилоняне? Скорее всего, да, знали, но трактовали это явление иначе, чем сейчас: для древнего шумерского инженера-информатика рациональное число 1/7 было бы не “рациональным”, а “невозможным”, в том смысле, что такую долю невозможно записать точно в шестидесятеричной системе, поэтому в точных таблицах нет обратного значения. Непонятно, как считать, поэтому 1/7 не должна встречаться на практике. Конечно, если 1/7 всё же встретилась, то инженеру-информатику пришлось бы воспользоваться таблицами “приближённых” значений, подобрав подходящий интервал. Такие таблицы тоже имелись, но их наверняка старались избегать, ведь иначе шестидесятеричная система оказывается избыточной.

12 июня 2025 года Boeing 787-8 Dreamliner (рейс AI171) потерпел катастрофу в Индии. Согласно предварительным результатам расследования (англ.) – на взлёте, в самом начале набора высоты, произошло отключение подачи топлива, полное, сразу на оба двигателя. Закрылки были выпущены на 5, что, оказывается, соответствует взлётной конфигурации (я в июне предположил, что закрылки “практически полностью убраны” – это так и есть, но, получается, что тут не повлияло практически никак).

Согласно записи регистраторов, тумблеры подачи топлива каким-то образом (объяснений нет) были переведены в положение CUTOFF (“Отключено”), практически одновременно (написано: 1 сек. между сигналами переключения тумблеров для каждого двигателя). Соответственно, двигатели начали останавливаться. На записи слышно, что один пилот спросил другого, зачем тот отключил подачу топлива, на что получил ответ – “я не отключал”. По отчёту, через (примерно) пять секунд, когда обороты упали ниже предела, вышла турбина резервного (аварийного) генератора (RAT), что видно на видеозаписи с камер наружного наблюдения, а ещё через пять секунд тумблер подачи топлива первого двигателя переведён в положение RUN (“Включено”), через четыре секунды – тумблер второго двигателя тоже переведён в RUN. Но это всё записи сигналов, как нетрудно предположить. На извлечённом из обломков секторе управления тягой ручки этих тумблеров так и стоят в положении RUN (в отчёте по ссылке есть фото). После разрешения на подачу топлива двигатели начали автоматически пробовать запуститься, но, понятно, времени уже на набор высоты не хватило. Довольно странная история.

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

О чём тут идёт речь? Существуют протоколы обмена командами и данным, в которых использование TLS встроено в схему протокола. То есть, на верхнем логическом уровне, не сам обмен протокола полностью и прозрачно завернут в TLS (как HTTP в HTTPS, скажем), а TLS можно включить, при наличии возможности, уже в контексте самого протокола – пример: SMTP + STARTTLS. То есть, сеанс в рамках атакуемого протокола обязательно начинается в открытом и незащищённом варианте. Это позволяет атакующему подменить начальные сообщения той или иной стороны, а потом переключить трафик на использование TLS: либо штатными средствами протокола, либо – перенаправив трафик на другой номер порта. Атакующий при этом должен активно перехватывать сетевое соединение, подменять пакеты и прозрачно перенаправлять трафик на разные номера портов. (В исходной публикации, для одного из сценариев, ещё и требуют выполнения атакующей стороной произвольного кода в контексте веб-страницы внутри браузера.)

Так, механизм STARTTLS для SMTP – тут сервер может предложить поддержку TLS в самом начале SMTP-сессии, а клиент, если он поддерживает TLS, может тут же начать переход на защищённое соединение, просигнализировав об этом серверу. Если переход на TLS произошёл, то SMTP-сессия начинается, фактически, заново – пусть и в том же сокете, но уже внутри TLS. Но для SMTP есть и вариант с прямым TLS-подключением, то есть, сразу по TLS на другом выделенном номере порта (например, 587, а не 25). Для осуществления атаки требуется, чтобы на сервере были доступны оба способа подключения – смысл и состоит в “перекидывании” сессии между открытым соединением и подставным TLS-соединением.

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

(Иллюстрация из исходной работы.)

Как ни странно, но TLS в “приспособительном” режиме возможен, – в теории, – и для HTTP. Этот вариант, впрочем, практически не встречается на веб-серверах: смысл для HTTP – тёмен, а настраивать нужно отдельно. Для случая HTTP последовательность данной атаки другая: атакующий модифицирует запросы, ответы и задерживает TLS-трафик так, что внутри TLS-сеанса оказывается ответ сервера не на легитимный запрос клиента, а на предыдущий запрос, поступивший к серверу от атакующего в открытом виде. TLS-опять же, атака не касается. Но, как и отмечено в исходной работе, все перечисленные атаки возможны потому, что TLS не предоставляет способа аутентифицировать состояние внешнего протокола на стороне сервера и клиента, а аутентифицирует только имена и адреса. Это так. Однако подобная расширенная аутентификация и не входит в модель TLS: несмотря на наличие расширений типа ALPN, TLS работает только на своём уровне. (Кстати, на ALPN описание атаки Opossum как раз ссылается: с ALPN связана вспомогательная часть и предыдущая атака по теме.)

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

Возьмём пару цитат и ещё одну, не менее замечательную:

“Нас невозможно сбить с пути, нам всё равно, куда идти”
М. М. Жванецкий(?), (есть вариант “никому не сбить”, не важно).

“У самурая нет цели – только Путь”
“Хагакурэ”, Ямамото Цунэтомо. (Иногда напоминаю коллегам эту важную максиму.)

Это почти об одном и том же. В первой цитате – всё равно, куда идти, но идти необходимо, иначе исчезает содержательная часть. Именно ход создаёт путь, который, по определению, тут не может вести к конкретной цели. Цели нет. Только Путь. Как и у самурая из второй цитаты. Почти.

“Всё равно куда” перекликается с одной из самых знаменитых цитат из “Алисы в Стране чудес”:

”
– Скажите, пожалуйста, куда мне отсюда идти?
– А куда ты хочешь попасть? – ответил Кот.
– Мне все равно… – сказала Алиса.
– Тогда все равно, куда и идти, – заметил Кот.
– …только бы попасть куда-нибудь, – пояснила Алиса.
– Куда-нибудь ты обязательно попадешь, – сказал Кот. – Нужно только достаточно долго идти.
“
Л. Кэрролл.

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

Занятно, что, согласно “Алисе в Стране чудес”, даже когда путь отделяется от цели, он обязательно приводит куда-нибудь. Это здесь чисто категорийное свойство пути – приводить куда-то. Стрелка.

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

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

Дзен самурая – дзен более высокого уровня, на фоне которого “всё равно куда” выглядит некоторым мельтешением: суетятся, бегают куда-то, всё равно, куда – лишь бы бегать. Самурай не суетится. У самурая нет цели. Только путь.

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

“\boxed{…” – выводилось в браузер несколько минут, но ничего кроме “\boxed{…” не появилось, так что пришлось остановить, переключив чат.