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

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

На скриншоте ниже – результат работы нехитрой программы на языке Python, которая вычисляет в точке x == i (мнимая единица) значение функции, известной как j-инвариант – j(x).

j(x) – это модулярная функция, которая важна, например, в теории эллиптических кривых, но в настоящей заметке теоретические детали не играют существенной роли. Значение j(x) для мнимой единицы – это целое число 1728 (в каком-то смысле, по определению). А 1728 == 12^3, что тоже не является простым совпадением, так как 12 == 2^2 * 3. Можно j(x) записать в виде бесконечной суммы (разложение Фурье или q-expansion, если хотите, где q == exp(2*π*i*x)), что и используется в программе: j(x) == q^(-1) + 744*q^(0) + 196884*q^1 + 21493760*q^2 + 864299970*q^3 +… Коэффициенты – целые числа.

Поскольку модулярные формы имеют большое значение в арифметике, коэффициенты из разложения j-инварианта проявляются в математике довольно неожиданным образом, порождая даже отдельные направления (как в случае “Чудовищной бурды” – Monstrous Moonshine, самогон, который в русскоязычной “Википедии” едва не превратился в “Монструозный отблеск”). Но это тема для другой записки, более подробной. Здесь же отметим, что так как коэффициенты – целые числа, можно взять их побольше (например, 42) и посчитать значение j(x) “численными методами”, проверив, сойдётся ли, и насколько быстро, результат. Понятно, что если в выражение для q (см. выше) подставить x == i, вместо i*i получится -1, что и делает каждый очередной элемент суммы всё меньше и меньше, несмотря на увеличивающиеся коэффициенты.

Однако здесь есть хитрости. Если использовать обычные настройки Python, то точности для вычислений не хватает, результат не сходится. Если взять math.exp() и math.pi, точность по умолчанию, получаем 1728.000000000000014825929946, причём ещё на 13 шаге суммирования – не очень-то хороший результат: больше чем 1728. Увеличение точности само по себе тут не помогает, нужно использовать модуль decimal и ввести достаточно длинные значения для π и e, заменив math.exp() и math.pi на Decimal(E**(Decimal(-2)*Pi))**n, где E и Pi – значения со многими знаками после запятой. Точность в decimal устанавливается при помощи getcontext().prec. Результат со скриншота получен для prec = 81 в Python 3.5. Всё это хорошо иллюстрирует, что компьютеры не считают в действительных числах.

Исходный код (проверьте, что символы табуляции не были “съедены” так же, как и некоторые цифры десятичного разложения):

from decimal import Decimal, getcontext
getcontext().prec = 81
Pi =	Decimal('3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982')
E =	Decimal('2.718281828459045235360287471352662497757247093699959574966967627724076630353547594571382178525166427427')
M = [
1, 744, 196884, 21493760, 864299970, 20245856256, 333202640600,
4252023300096, 44656994071935, 401490886656000, 3176440229784420,
22567393309593600, 146211911499519294, 874313719685775360,
4872010111798142520, 25497827389410525184, 126142916465781843075,
593121772421445058560, 2662842413150775245160, 11459912788444786513920,
47438786801234168813250, 189449976248893390028800, 731811377318137519245696,
2740630712513624654929920, 9971041659937182693533820, 35307453186561427099877376,
121883284330422510433351500, 410789960190307909157638144, 1353563541518646878675077500,
4365689224858876634610401280, 13798375834642999925542288376, 42780782244213262567058227200,
130233693825770295128044873221, 389608006170995911894300098560, 1146329398900810637779611090240,
3319627709139267167263679606784, 9468166135702260431646263438600, 26614365825753796268872151875584,
73773169969725069760801792854360, 201768789947228738648580043776000, 544763881751616630123165410477688,
1452689254439362169794355429376000
]
j = Decimal(0)
n = -1
for c in M:
	j = j + Decimal(c) * Decimal(E**(Decimal(-2)*Pi))**n
	print("j = ", j)
	n = n + 1
print("j^(1./3) =", float(j)**(1./3))

“Демультиплексирование” на общем номере порта TCP протоколов более высокого уровня (TLS/XMPP/SSH и т.п.) при помощи сигнатур начальных пакетов, описываемых регулярными выражениями, имеет и особенности “в другую сторону”: всё, что можно на уровне сокета разобрать (статическим) регулярным выражением на стороне сервера, можно быстро разобрать регулярным выражением и на стороне системы DPI. Естественно, в модели, приписывающей существенный вес номеру порта TCP в классификаторе протоколов, такой программный демультиплексор на серверной стороне был бы достаточно эффективен, но в более широком понимании – метод слишком далёк от стеганографического.

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

DKIM предложили в целях борьбы с нежелательной рассылкой сообщений, когда почтовый адрес отправителя подделывается (в e-mail не предусмотрено защиты от этого). Сейчас почтовый сервер без DKIM для отправляемых сообщений держать не принято – могут быть проблемы с доставкой, некоторые серверы на стороне получателя автоматически классифицируют входящие сообщения без DKIM как спам.

Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).

Заметьте, что наличие или отсутствие DKIM не вводит каких-то технических обязательств на принимающей стороне: технически, DKIM – это дополнительные поля (заголовки) в не менее техническом конверте, сообщение всё равно приходит на принимающий сервер обычным способом, а этот принимающий сервер прекрасно может игнорировать заголовки DKIM. То есть, включение DKIM вовсе не влияет на базовые механизмы доставки почты, это протокол уровня политик, в его работе всё зависит от настроек, используемых сторонами.

Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.

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

Ключевым моментом эффективности DMARC является не состав политики, а то, поддерживается ли DMARC принимающим сервером, а если поддерживается, то как именно. Сама по себе публикация сведений DMARC не обязывает принимающий сервер не только следовать опубликованным политикам, но даже и запрашивать их из DNS: для приёма и обработки сообщений это не требуется (как не требуется и возможность обработки DKIM). Конечно, грамотно настроенный сервер должен обрабатывать и DKIM, и DMARC, однако такая настройка вовсе не обязательно означает, что письмо без DKIM будет молчаливо отброшено, если принимающий сервер обнаружит политику reject в DMARC. Другими словами: DMARC носит более чем рекомендательный характер, поэтому целиком полагаться на указание политики обработки нельзя.

Квантовая часть алгоритма Шора, если его вообще возможно реализовать, выглядит примерно следующим образом. Первому квантовому регистру назначается состояние, представляющее собой суперпозицию всех входных числовых значений. То есть, предположим, что это 1024 “битовых разряда”, тогда получается 2^1024 различных (числовых) значений и тому подобные штуки. Однако физические детали существенно отличаются, при этом основная идея вообще не касается выбранной реализации. То есть, традиционно, в качестве примера приводят отдельные “кубиты”, как некие “конструкты”, принимающие два состояния (“спин вверх/спин вниз” или что-то похожее, это довольно сложно представить) и совместимые с представлениями о суперпозиции. В квантовой суперпозиции и состоит смысл этих конструктов, так что реализация входного регистра не важна: он является лишь входом, через который основную схему предлагается “подключить”, если хотите, к квантовой ирреальности.

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

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

Если вспомнить математическую часть алгоритма, то речь про вычисление y = A^x (mod M). Обратите внимание на значение A (натуральное число), которое задаёт конкретную схему аппарата для запуска алгоритма Шора! При последовательном вычислении y = A^x (mod M), если показатель x пробегает достаточное количество значений, результат (y) начнёт повторяться, это теоретико-числовая польза от алгоритма, потому что позволяет определить, при каком x A^x == 1 (mod M) и т.д., этому как раз соответствует период данной функции, который мы хотим определить квантовой машиной. Конечно, в случае квантовой машины, никаких подобных вычислений нет: такая машина – супераналоговый прибор, возможно, что ламповый, но скорее холодный, чем тёплый: выход в квантовую ирреальность почему-то требует низких температур. В общем, не предполагается, что происходят какие-то шаги, кто-то переключает реле и сигналы, а на вход “блока функций” поступают разные “иксы”, пусть даже и параллельно. Нет, напротив, подключается несколько миллионов (предположим) загадочных “гейтов”, объединённых в схему, задающую функцию для проверяемого значения A, и всё – предполагается, что в финальном измерении через схему пройдёт поток вероятности, который преобразуется нужным способом и выльется во второй регистр.

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

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

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

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

(См. также про алгоритм Шора и Вселенную кубиками.)

Вообще, эта история с встраиваемой в посторонние сайты браузером Firefox рекламы Mozilla VPN тоже имеет отношение к стремительно наступающему Новому Средневековью. Скорее всего, в этом конкретном случае, у пользователя всё ещё имеются возможности не подключать “промо” или “отписаться” (как минимум, сообщают, что можно выключить флаг в настройках браузера – что, конечно, само по себе показательно: флаг для отключения встроенной в браузер рекламы). Важно совсем другое. Ещё некоторое время назад разработчикам браузера могло бы показаться, что задача браузера состоит в отрисовывании веб-страницы максимально близко к некоторым спецификациям (“веб-стандартам” и пр.). Идея воспользоваться статусом браузера и модифицировать визуальное оформление страницы так, чтобы закрыть его собственной рекламой, должна была бы быть отброшена. Это не отменяет богатой истории подобных подмен, начиная с массового перенаправления “несуществующих доменных имён” с использованием положения провайдера авторитативных серверов DNS и вплоть до вмешательства в HTTP-трафик на стороне провайдера доступа или даже на транзите. Наоборот, такой исторический опыт и должен бы приводить к тому, что в приличном браузере подобные практики не могут рассматриваться. Но, конечно, не в условиях Нового Средневековья.

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

Пока что с Firefox это не сработало: пользователи всё поняли правильно и даже возмутились. Не факт, что это будет иметь долгий эффект: интернеты становятся “корпоративными”, в том числе, на стороне клиента. Нужно ли ожидать рекламных пауз в ядре Linux? Риторический вопрос.

Попытаться построить квантовый компьютер на тысячи кубитов имеет смысл хотя бы для того, чтобы проверить, что имеющиеся модели работают для больших пространств состояний. Попытка факторизации 1024-битного числа на гипотетическом квантовом компьютере при помощи алгоритма Шора сталкивается с необходимостью как-то действовать в пространстве из 2^1024 состояний (ну, предположим). Влезет ли такое количество состояний во Вселенную? Насколько 2^1024 вообще большое?

Понятно, что какие-то прямые физические воплощения для такого числа придумать не получится, поскольку, например, 2^1024 несравнимо больше, чем масса Земли, подсчитанная в граммах. Но можно пойти на комбинаторные ухищрения. Нарежем пространство Вселенной на 2^80 небольших кубиков. 2^80 выглядит очень похожим на разные оценки “объёма Вселенной”, “количества частиц” и других сходных параметров. Перестановкой этих кубиков можно получать разные конфигурации Вселенной, которые, возможно, будут весьма сходными. Предположим, что количество конфигураций это (2^80)! (факториал, а не восклицание). “Реальный”, – что бы это ни значило, – показатель может быть другим: нужно учитывать возможности по сочетанию получившихся кубиков, их взаимное расположение. Однако для нашего примера это не важно.

Существенно ли (2^80)! превосходит 2^1024? Может показаться, что 2^1024 очень большое число. Однако провести сравнение нетрудно. Заметьте, что при вычислении факториала каждое чётное число повышает степень двойки (иногда – больше чем на единицу), поэтому 2^1024 вкладывается уже в 1026! (ну или примерно так; 1026 = 1024+2, проверьте; естественно, 171! больше 2^1024). Что уж говорить про (2^80)!! (Здесь второй восклицательный знак обозначает восклицание.) Теперь может показаться, что 2^1024 не такое уж и большое число, чтобы не вкладываться в качественно нарезанную Вселенную.

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

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

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

В быту 3D-принтер полезен тем, что можно напечатать разные уникальные изделия, “оптимизированные” для решения конкретной задачи. Например, я напечатал ремонтную деталь для блока кнопок управления автомобильным креслом: можно было бы заменить весь блок целиком (хорошо, что не кресло), но это потребовало бы снятия кресла – достаточно много работы. Это далеко не единственный пример. Так, из недавнего, я спроектировал и распечатал несколько установочных кронштейнов для крепления небольших солнечных батарей (для питания уличных светильников), кронштейн для установки самого светильника под скатом крыши, несколько элементов крепления видеокамер, немало коробок-корпусов для разных самодельных устройств вроде цифровых термометров и часов с GPS-коррекцией, несколько защитных кожухов для различных простых механизмов (вроде замка уличной калитки) и другие подобные изделия. Модели я готовлю в OpenSCAD, это очень удобно. Сейчас я в основном использую FDM-принтер Anycubic Mega X – о чём рассказано в отдельной заметке (с картинками). Этот принтер работает методом последовательного наплавления слоёв пластика, то есть, он состоит из нагреваемого столика, над которым перемещается печатающий узел с горячим соплом (“хотэндом”) экструдера.

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

Основные проблемы всегда доставляют участки модели, которые нависают над столиком. Очевидно, что FDM-принтер не может печатать “в воздухе” – пластик будет просто вытекать вниз. Обычно, для того, чтобы печатать “нависающие” поверхности, используются подпорки. Подпорки здесь – это достаточно лёгкие структуры, которые принтер печатает, начиная от столика, и которые потом можно удалить, отломив или отрезав от изделия. Подпорки добавляются в описание модели для печати. Слои основного изделия, соответственно, накладываются на подпорки. Убирать подпорки, например, у резьбы – весьма сложно: смысл теряется. (Бывает ещё вариант с печатью подпорок другим типом пластика, например, водорастворимым, но для этого принтер должен иметь два печатающих узла.)

Так вот, у всякого FDM-принтера, тем не менее, есть некоторая “степень нависания” слоя, которую принтер может распечатать без подпорок, если только соответствующая часть изделия “вырастает” из другой части, а не висит уж совсем отдельно. Это объясняется достаточно просто: если очередной слой лишь немного “свешивается” за край предыдущего, то свежий пластик успешно приклеивается к этому краю и не провисает, так как застывает достаточно быстро (тут главное не использовать ни слишком высокую скорость движения печатающего узла, ни слишком низкую). Это отлично работает как для резьбы, печатаемой вертикально, так и для других моделей (в принципе, можно даже печатать небольшие горизонтальные “прогоны”, на небольшой скорости). Что, собственно, и составляет один из методов оптимизации: углы “нависания” нужно проектировать так, чтобы принтер справился без подпорок. Да, это вводит ограничения на конструкцию изделия, поэтому может составить проблему, если использовать готовую модель. Однако если модель проектируется под конкретную задачу с нуля, этот момент можно учесть, что, в общем-то, является обычным технологическим аспектом разработки (не только в случае 3D-печати).

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

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

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

Оказывается, некоторое время назад в Google добавили занятную функцию в приложение для (так называемой) “двухфакторной аутентификации” (2FA), а именно – возможность восстановления “из облака” в случае потери устройства. Заметьте, что весь смысл “двухфакторной аутентификации” состоит в том, что подключающийся пользователь может доказать, что у него есть доступ к дополнительному секрету, кроме пароля, который могли и украсть. Естественно, этот дополнительный секрет может проявляться как “одноразовые пароли” или какие-нибудь PIN-коды, которые, например, генерируются в зависимости от текущего времени (и от значения секрета, конечно).

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

С этим обновлением мы вводим решение проблемы – делая одноразовые коды более надёжными путём безопасного хранения их в Google-аккаунте пользователя.
(With this update we’re rolling out a solution to this problem, making one time codes more durable by storing them safely in users’ Google Account.)

То есть, наличие потенциальной привязки к аппаратному устройству делало 2FA полезным инструментом, однако Google предлагает передать дополнительный пароль на внешние серверы, в результате чего вторым фактором оказывается Google-аккаунт. Теперь, если пользователям некоторой корпоративной системы предложено использовать Google Authenticator в качестве хранилища второго секрета (распространённый случай), то это означает, что доступ к системе завязан уже даже не на неконтролируемое приложение от третьей стороны, а прямо на аккаунт Google.

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

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

Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в DNS, и в HTTP. А вот часть URL, соответствующая адресу документа, уже в DNS не ходит. Другими словами: используем в браузере (условный) URL https://123dio.cba.example.net/an-img.gif, где полезные данные кодируются в части 123dio.cba. Строка 123dio.cba.example.net отправится и в DNS, где будет узнана специальным сервером, и в HTTP, а вот an-img.gif – в DNS не попадёт, а поступит только на веб-сервер, отвечающий под 123dio.cba.example.net. Соответственно, насыщение HTTP-запросов полезной информацией, которую мы хотим видеть и в DNS, должно происходить через имена хостов.

Однако возникает неприятная проблема с HTTPS: дело в том, что для установления соединения с браузером сервер под “странным” именем 123dio.cba.example.net должен предъявить TLS-сертификат, валидный для этого имени, но имя-то каждый раз разное, поэтому сертификатов не напасёшься (если их выпускать через тот или иной УЦ, признаваемый браузерами). Использование открытого HTTP тут не рассматриваем – такие условия: хотя бы потому, что страница-носитель загружается по HTTPS. Что можно сделать? А можно, например, совсем отказаться от установления TLS-соединения на стороне сервера и при этом не потерять полезных данных. Нам не требуется реально обрабатывать HTTP-запрос и возвращать файл изображения, нам нужно только зафиксировать на сервере имя хоста, а это имя в HTTPS/TLS передаётся клиентом в начальном сообщении, да ещё и в открытом виде (это как раз и есть SNI TLS). Так что серверный сертификат тут просто не нужен: сервер записывает имя хоста из SNI и – прерывает соединение с тем или иным кодом ошибки TLS.

(Дополнение – 30/04/2023: в комментариях справедливо указывают на wildcard-сертификат для имён вида *.example.net. Однако тут такой сертификат не сработает, поскольку для DNS-части измерений важны кодирующие имена минимум в двух уровнях, то есть, *.*.example.com, а wildcard-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)