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

В быту 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.

Если при наборе термина “A-запись” использовать английскую раскладку (привычную), но ошибиться с выбором кнопки на клавиатуре по обозначению (кириллическая “А”), то относительно русской раскладки получится “F-запись”. Если раскладку не переключить, оставить русскую, но кнопку выбрать “обратную”, то получится “Ф-запись” (проверьте). Таким образом, данный термин содержит в себе некоторый хитрый антиомоглифический инвариант.

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

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

– Хотелось бы сказать, что я рассказываю про объекты, о существовании которых большинство людей даже не догадывается. Но это не так: мало кто догадывается, что существует сама возможность обсуждать существование или несуществование этих объектов.
– Интересно. И что же это такое?
– Да, именно. Об этом и речь.

(Продолжаем рассматривать занимательные знаки в манускриптах.) В Unicode есть лигатура ϗ, обозначающая древнегреческий союз καί и совпадающая по свойствам и значению со всем знакомым знаком “амперсанд” (& – происходит от латинского et). Занятно, что в старых (9 – 12 века) манускриптах сокращённое древнегреческое καί нередко выглядит похожим на S (но, согласно справочникам, встречаются и весьма экзотические варианты, например, очень близкие по начертанию к @ – такой вариант, похоже, был почему-то популярен в 14 веке, но это вряд ли связано с распространением Интернета). Вот на картинке ниже “скриншот” из манускрипта Venetus A десятого века, который содержит текст Илиады (на этот знаменитый манускрипт традиционно ссылаются, когда нужно привести пример достаточно старого и полного текста Илиады).

(Сокращения καί отмечены стрелкой, штрих “акцента” – тоже входит в обозначение.) Но сам знак ϗ происходит из приписывания к каппе (“κ”) сокращённой записи для “αι” (она как раз похожа на растянутую s): то есть, сокращению в ϗ подвергается не слово целиком, а только часть.

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

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

В апреле 2023 на dxdt.ru вышло достаточное количество записок, чтобы некоторые из них отметить отдельно, а именно:

• Gitea и омоглифы не в ту сторону
• Poison-расширение и SCT-метки в Certificate Transparency
• “Начала” Евклида, палеография и особенности чтения манускриптов

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

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

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

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

Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в 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-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)

На картинках ниже – замок Fichet 787 с “рычажным” механизмом (источник фото: Toool Blackbag).

Замок в разрезе и ключ (фото: CC-BY-4.0 Jan-Willem, Toool Blackbag).

Фрагмент основной части механизма (фото: CC-BY-4.0 Jan-Willem, Toool Blackbag).

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