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

Ниже приведён скриншот манускрипта конца 13 века (Adv.MS.18.7.15, древнегреческий) из коллекции Национальной библиотеки Шотландии (в коей библиотеке электронные архивы, как и дистанционный доступ к ним, пока что сохраняются). Фрагмент, на минуточку, относится к переписанной грамматиком Планудом (скорее всего) работе философа Клеомеда, в которой пересказан метод определения периметра большого круга Земли (длины меридиана), использованный древним греком Эратосфеном. Плануд переписал труд Клеомеда в 13 веке (результат – на скриншоте), а исходный труд Клеомеда, как предполагается, относится к периоду с первого по четвёртый век н. э., а вот сам Эратосфен выполнял описанные геометрические расчёты на рубеже третьего и второго веков до н.э. То есть, тут, примерно, полторы тысячи лет, в ходе которых Земля описывается как круглая (круглая Земля, заметьте, тоже может перевозиться большой черепахой, но это другая история).

Cleomedes

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

Исходя из расстояния от Сиены до Александрии (по большому кругу) в 5000 стадиев, Эратосфен определил общую длину меридиана в 250 000 стадиев – соответствующая строка манускрипта выделена зелёными метками (середина скриншота): “ὁ ἄρα σύμπας κύκλος γίνεται μυριάδων εἴκοσι πέντε” – так будет в современной типографике, но в манускрипте записано с кучей скорописных сокращений (и прочих “смайликов”), поэтому на современные начертания букв не очень-то похоже. Само число, кстати, указано как двадцать пять мириад (μυριάδων, двадцать – εἴκοσι, пять – πέντε). Двадцать пять мириад стадиев, – то есть, примерно, от 44 до 52 тыс. км, – неплохо соответствует современным оценкам в сорок тысяч километров.



Комментировать »

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

Понятно, что результат радара – это далеко не цветная картинка, полученная телескопом для публикации в Google Earth (см. наложение ниже). Но у радара целый ряд преимуществ, тем более, если речь идёт об орбитальной радиолокации с разнесением передатчика и приёмника. Такой орбитальный радар видит ночную часть земной поверхности, может просвечивать не только сквозь облака, но и через некоторые наземные укрытия; зондирующий радиосигнал с высокой разрешающей способностью позволяет отличать макеты техники от настоящей техники и, в теории, может даже извлекать сведения о подземных коммуникациях (находящихся на небольшой глубине в подходящих почвах) и обнаруживать подвижные субмарины в подводном положении (по спутному следу). Спутники Umbra находятся на высоте около 550 км (450 – 600 км), а низкая орбита тоже приносит свои преимущества, даже по сравнению с самолётами. (Но, например, на радарной картинке не видна надпись, нанесённая на основание плотины с иллюстрации ниже.)

В качестве иллюстрации работы бистатической радиолокации Umbra публикует изображение дамбы большой ГЭС в Пакистане.

Общий вид:
SAR image, UMBRA
(Cпутниковый радар Umbra.)

Выделен фрагмент, который ниже дан с увеличением до “пиксел в пиксел”:
SAR image, UMBRA
(Umbra.)

Фрагмент с большим разрешением
SAR image, UMBRA
(Umbra.)

Примерное наложение на снимок, доступный в Google Earth:
SAR image, UMBRA
Занятно, что совпадает почти вся техника, выставленная во дворе (Umbra/Google). От Umbra, кстати, есть немало данных в открытом доступе.



Комментировать »

Современные компиляторы хорошо умеют оптимизировать машинный код и обычно делают это гораздо лучше разработчика. Но нужно учитывать тот факт, что программа на некотором языке высокого уровня (ЯВУ) – это не алгоритм, а только запись алгоритма. Соответственно, компилятору принципиально доступны лишь структуры, нашедшие отражение непосредственно в записи, но не сам алгоритм. Один и тот же алгоритм вообще можно записать многими способами и на разных языках. Так что компилятор, в процессе перевода с входного ЯВУ на машинный язык, оптимизирует языковые конструкции. Компилятор не видит алгоритм и не может его оптимизировать. Разработчик, в теории, способен оптимизировать именно алгоритм, это следует из того, что разработчик как раз “переводит” (записывает) алгоритм на ЯВУ (но, конечно, лишь в том случае, если код пишется не силами очередного ИИ/LLM/ChatGPT, выстраивающего “токены” в псевдомарковскую цепь). Поэтому иногда нужен ассемблер.

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

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

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



Комментировать »

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

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

Google Safe Browsing and Proxy
(Image: Google.)

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

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



Комментировать »

В конце 2022 года я добавил в DNS для dxdt.ru HTTPS-запись, которая тогда была описана в черновике RFC. В ноябре 2023 года черновик стал RFC 9460, где определяется способ публикации в DNS дополнительной информации о параметрах подключения к сервисам, связанным с данным именем. Например, это могут быть параметры для TLS/HTTPS, в том числе, ключи (см. ECH). Особенность использования DNS тут в том, что параметры можно получить до подключения, это, в свою очередь, позволяет устанавливать скрытые подключения.



Комментировать »

Воскресное чтение манускриптов. В этот раз – небольшой скриншот манускрипта Barb.gr.580 (древнегреческий, видимо, 11 или 12 век) из Ватиканской Апостольской библиотеки. На скриншоте небольшой фрагмент одного из комментариев (тридцать второго, если точнее) Иоанна Златоуста к Евангелию от Матфея. Этот фрагмент, заканчивающийся узнаваемым сочетанием слов – “учителями и врачами”, – содержит сразу несколько занятных сокращений, которые распространены в манускриптах соответствующего типа и периода.

Vat.Barb.Gr.580

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

Пара других примеров труднодоступной для чтения скорописи отмечены в конце первой строки скриншота: левее – скорописью записано φησὶν (“говорит”), а следующее загадочное сочетание лигатур – это ἐπει в ἐπειδή (“когда”, “после того как”).



Комментировать »

Reuters раскрывает в эксклюзивном материале очередной секрет Полишинеля: SpaceX, пишет Reuters, строит “сеть из сотен спутников-шпионов” в интересах профильного штатовского агентства (NRO). Спутниковая сеть позволит вести мониторинг всей земной поверхности.

Цитата из записки про SpaceX и орбитальный радар, опубликованной на dxdt.ru в 2018 году: “получаем адаптивный орбитальный радиолокационный комплекс, который наблюдает всю поверхность Земли – технология, сошедшая со страниц научно-фантастических романов”. История движется, и теперь можно написать, что технология “сошла со страниц эксклюзивных публикаций Reuters”.

Направление это весьма интересное, так что про особые возможности больших группировок низкоорбитальных спутников, – в основном, это SpaceX/Starlink, – я писал не раз:

Инфракрасные сенсоры на орбите;
Низкоорбитальные сенсоры как наблюдательные сети;
Наземные терминалы Starlink как элементы радара;
Спутниковые системы для ЭМ-атак;
Starlink и взаимодействие с наземными GSM-сетями.



Комментировать »

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

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

Picture of Glen Canyon Dam

(Изображение: Glen Canyon Dam, Wikimedia.org)



Комментировать »

The New York Times рассказывает (там много букв), как в Штатах водители современных “подключенных” автомобилей (то есть, автомобилей, у которых есть привязанное приложение с интернет-подключением) внезапно обнаружили, что очень подробные данные об их поездках передаются “скоринговым агентствам”, а статистика потом прямо влияет на стоимость страховки (“опасное вождение” и тому подобные эффекты). Данные, при этом, передаются через производителей автомобилей.

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

(via)



Комментировать »

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

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

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



Комментировать »

Один из самых знаменитых в мире чипов известен как “555-й таймер” или просто как “микросхема 555”. На Hackaday публикуют описание его полнофункциональной “развёртки”, выполненной из SMD-компонентов на плате, которая по форме повторяет три пятёрки – см. картинку.
Timer 555



Комментарии (1) »