На Ars Technica попался занятный краткий обзор научного исследования, посвящённого выяснению того, как использование в заголовках СМИ оборотов типа “учёные полагают”, “учёные думают” (в оригинале – scientists believe, так как исследование об английском языке) влияет на читательскую оценку “достоверности” понятий, упомянутых в том же заголовке. Собственно, противопоставлены там слова “думать/полагать” (believe) и “знать” (know), а абсолютно точно перевести на русский довольно сложно. То есть, предположим, читатели читают заголовки: “Учёные думают, что на Марсе есть вода” и “Учёные знают, что на Марсе есть вода” – влияет ли разница в семантике заголовков на классификацию конкретным читателем утверждения “на Марсе есть вода” как являющегося бесспорным “научным фактом” или как “одного из возможных мнений”? Исходное исследование строится на опросе многих людей-участников, которым предлагали оценить различные варианты заголовков.

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

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



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

Пишут, что в Штатах, из-за проблем с GPS, вызванных солнечной активностью, современные тракторы (John Deere и др.) не могут обеспечивать посев семян фермерами. Эти тракторы автоматически ориентируются по GPS, но, как утверждается, из-за возникшей дополнительной погрешности, могут проложить борозды так, что при следующем заходе сами их не найдут: то есть, из-за разного навигационного поля между итерациями, система траекторий, записанная техникой, будет по разному отображаться на реальное поле между, предположим, посевом и последующей обработкой (или сбором урожая). Соответственно, трактор может просто позже наехать на растения. Тракторист не имеет возможности компенсировать ошибки, так как точности ручного управления, якобы, не хватает (скорее всего, просто не предусмотрено такой функции – современная сельскохозяйственная техника бывает автоматизирована даже на уровень выше, чем авиалайнер). И это всё довольно интересный, с точки зрения Нового Средневековья, технологический эффект, если так.

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



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

Stack Overflow некоторое время назад запретил использование LLM (ChatGPT и пр.) для генерирования и ответов, и вопросов на сайте. Причины запрета были названы разные, но ситуация стала особенно забавной на днях, когда из OpenAI объявили, что контент Stack Overflow будет официально предоставлен для “обучения” ChatGPT (пока что – несмотря ни на какие протесты некоторых пользователей). То есть, если бы изначального запрета на использование LLM не было, то могла бы возникнуть ситуация, когда в ChatGPT транслируется выдача ChatGPT, что далеко не всегда хорошо (хоть и составляет существенную часть штатной работы данных LLM).



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

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

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

Вот, судя по описанию, сходным, – но не совсем похожим на описанный выше, – образом, и работает сервис от Flightradar24, показывающий помехи GNSS.

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



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

Что касается новостей про атаку TunnelVision, которой соответствует CVE-2024-3661, и про которую сейчас СМИ пишут, что это “уязвимость всех VPN”. Очень (слишком даже) подробное изложение есть по исходной ссылке, однако там начинается весьма издалека, с самых азов. Но для сетевого инженера саму атаку можно детально описать в несколько строчек: к VPN это отношения не имеет, а речь идёт про добавление маршрутов на клиентское устройство средствами DHCP-сервера, маршруты, соответственно, добавляются с привязкой к сетевому интерфейсу на уровне ОС клиента и ведут на перехватывающий узел в той же локальной сети. Дальше работает more-specific, потому что для интерфейса VPN прописано, предположим, 0.0.0.0/0. Понятно, что таким способом можно перенаправить произвольный IP-трафик на промежуточный узел до того, как этот трафик уехал на клиенте в туннельный интерфейс, поднятый приложением VPN. Трафик поэтому будет в открытом виде. Это, собственно, всё.

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

Собственно, авторы исходного сообщения прямо пишут, что вопрос, является ли TunnelVision уязвимостью – спорный, а дальше объясняют, что публикация направлена на противодействие массовым маркетинговым уловкам провайдеров VPN-сервисов, когда заявляется, что какой-то VPN-клиент защищает трафик при подключении к “недоверенной сети”.



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

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

В начале первой строки нетрудно заметить нагромождение букв в два ряда:
Screenshot

Оказывается, что это всего лишь слово “ἔχει” (“имеет”, в данном случае), в котором ε “упала”, а над увеличенной χ установлена лигатура ει. Вместе с соседними словами получается “τοῦτον ἔχει τὸν λόγον” – “такое [же] имеет соотношение”. Речь идёт о сравнении длин дуг, использованных при построении планиметрического обоснования для способа вычисления длины земного меридиана, предложенного Эратосфеном. Слово “ἔχει” используется часто, но всё же не похоже, чтобы подобное написание действительно позволяло экономить немного дорогостоящего места на пергаменте: “экономичные” сокращения выглядят иначе. Так что, скорее всего, данный “вензель” – это лишь элемент стиля.



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

Снова пишут про то, что в TLS браузера Chrome длинное ClientHello с ключом Kyber768 ломает обработчики TLS-трафика на каких-то “специальных” веб-серверах и на промежуточных фильтрах. Между тем, чтобы разобраться, как там и что происходит, достаточно посмотреть на конкретное ClientHello, но в некоторых деталях. В качестве примера я взял сообщение от браузера Chrome 124 в том виде, как оно отображается на тестовом сервере TLS. Чтобы просмотр дампа не был скучным, листинг перебивается техническими пояснениями.

Итак, ClientHello TLS 1.3 с постквантовой криптосистемой Kyber768 внутри. CH здесь уже извлечено из TLS-записей и разобранно на элементы: то есть, здесь не учитываются и не упоминаются дополнительные байты, которые расходуются внутри структуры CH на представление полей – идентификаторы, длина записи; обычно – это несколько дополнительных байтов на один элемент структуры. Если бы разбирать и эти байты, то описание излишне усложнилось бы (подробности – можно прочитать в техническом описании TLS).

Version: 0x0303
Cipher suites:
 0xBABA,0x1301,0x1302,0x1303,0xC02B,0xC02F,0xC02C,0xC030
 0xCCA9,0xCCA8,0xC013,0xC014,0x009C,0x009D,0x002F,0x0035

Начальная часть сообщения ClientHello (далее – CH) содержит “исторический” номер версии (здесь указано 0x0303) и перечень шифронаборов. Полезных данных: два байта – номер версии, 32 байта (16*2) – идентификаторы шифронаборов.

 
Client Random: 
85:32:22:08:24:07:B2:98:F3:23:08:4D:A5:FB:E4:59:41:93:13:88:AA:58:53:4E:B4:EF:E7:DA:E8:78:FE:71
Client SessionID: 
C0:39:BC:CE:BB:60:5F:76:D8:75:F9:84:69:E9:9F:C2:AE:7B:8F:D5:9C:E8:01:51:71:9D:21:D2:13:26:DB:5A

Случайное значение от клиента (Client Random). А также клиентский “идентификатор сессии” – в TLS 1.3 этот идентификатор играет роль простого сигнала и ни на какую сессию не указывает.
Здесь всего 64 байта данных, по 32 на каждое поле.

Далее идёт важная часть, которая, собственно, определяет значимые параметры TLS-соединения – набор расширений CH.

Extensions:
 Type: 14906 (0x3A3A); "_undef_ (GREASE)"
 Type: 35 (0x0023); /non-TLS-1.3/
 Type: 23 (0x0017); /non-TLS-1.3/
 Type: 16 (0x0010); "application_layer_protocol_negotiation"
  00:0C:02:68:32:08:68:74:74:70:2F:31:2E:31
 Type: 65281 (0xFF01); /non-TLS-1.3/
  00

Здесь 0x3A3A (тип 14906, первое расширение) – это пример того, что называется GREASE, а именно – специальных, заведомо неподдерживаемых, значений и идентификаторов, которые Chrome дописывает в TLS-сообщения с целью (как заявлено) проверки корректной работы парсеров и прочего программного обеспечения, задействованного в обработке TLS. Такие обработчики, согласно спецификации, должны успешно игнорировать неизвестные расширения и параметры (если контекст позволяет, конечно). Так что, вообще говоря, добавление разных там новых “постквантовых ключей” не является чем-то особенным – всякие фиктивные элементы писались в браузерные сообщения и раньше, именно для того, чтобы обновления не оказывались полной неожиданностью (ниже нам встретятся и другие GREASE). Другие расширения из этого фрагмента, с типами 35 (session_ticket), 23 (extended_master_secret), 16 (ALPN) и 65281 можно не рассматривать: они небольшие по объёму (например, extended_master_secret – это всего лишь сигнал, вообще не содержащий байтов данных), часть из них не поддерживается в TLS 1.3. Поэтому – переходим дальше.

Как говорится, а вот и он – постквантовый элемент. Клиентский открытый ключ Kyber768 содержится уже в следующем расширении – key_share. Оцените огромный размер данных, которые тут приводятся без сокращений.

 Type: 51 (0x0033); "key_share"
  _undef_ (GREASE) (0xAAAA)
   Unsupported group: 0xAAAA (_undef_ (GREASE))
  X25519Kyber768Draft00 (0x6399)
   Hybrid: X25519 + Kyber
   Len (octets, dec.): 1216
   Key share data:
    X25519
     x = 0xF2C744A07B3BC36F6C427620351A009D29BB36E6EF259A177A3881ECEB22100D
    Kyber768 client public key:
     Vpoly_1 (packed):
      6CA39FB332275395989A56958E6B61A7B3B447D6A2C9062837E39695B44E4A5B
      36C9A7B06F4A912ED6ABC2E3BD2FD8584BE42F5822A3A54A4CC14812F3D87A05
      5371F2E1222817A63FAA531CD7691DE59694F9B4ACD3B8CD638A44B9B566C094
      3A95B7DCB186CC840C53A90041FB15FFBB214E3BCE8AB0C3D278897A61992601
      BB88427608A8AEC6385C0C6319A56B8B47CA240F3A134DD6AF4B56A6333158A9
      D391B495A76EA0C5F67C49457042AFFB508766414C88A8EA23B1328723FC9199
      8BA78414527F2DC234C0213CF5DAB976910EA3DC641C8B818FF73F4CEB53C929
      C03F61CFD8A04CE88A3EB16CCAE02C9541438A16D4A7FE8129F7F04C0C0A9E14
      60ACA4049F84C2C4E5DB1B4185CF0FE8C305333CBC7B3970A27E42C23F47F003
      E3815FDE20830B912501E388BEB9B14399ADD2EA174E3C040810917E555084E1
      5B75B9599914523799B6885721D08A46741501EBACA747C905B7AA31E3D3137C
      718B50A908DC111E49161448B102D3F0411EA70D9F91CFF6F50D5D54B9AB7B11
     Vpoly_2 (packed):
      1356BAA03CAD6E2730C334C24D492E6A11088F7B036A7ACBEF26407C1A9DCDFA
      473D677C3447915AE28EB094326093668FC27DCB85086219A1A0E6A6FC367CE0
      9A4396EA75FAFA1CD336311DE505BE5075A36C436B58673CF6387AF45BDBD523
      C082864EB6BD20E6A587C99976FA04C9548FB9731BC5B80D483984D8E84D89A3
      8A0D210D58C22C9DA0316D9214B45B46C7353228C67A62F101DD79267C071CEE
      9C1FA2DA976294AD6031C245397BDFB11A3AF012DF154B6D126439F579F85C38
      77AB844586159ECCAD0D468A3D94A5DABA43B26722B4C24FEFDC19FC62355341
      29B1FBABC7D242DDEB59DB00C564546DBD384653CCB55436BCCA4B7C4BA585E3
      50B078A48B8F02C9BA79154DF463E42538DB7616AC04C9C1284F0E2918009CAE
      49EB18708A2BD322A3A613CCCF43B3CA288780546FEBF03B6FC3394816359406
      5642DC4930B4B36D5B5122A90871006975496515650608E632414B5054019BB5
      CB280DF34DA9087AB2FA2ADB94588AB2A8C8D3CA3DAB7248357001D0C175269C
     Vpoly_3 (packed):
      AAF30D9EA1ADEF802799581653A0A0D4D692EB2B644F6C84059388947838138A
      1D24464054A9A3E9385FD3E4A6C0C56D09D80F984705B2E4B4244A4D67C3CD58
      7739688170695AC9AA4C354A349AB04ACBD4753E6B519468EB900A290C3AD255
      A004307B1572C0072946B73639F897D434086C515F6BBA53BB10B6A3D4B4AC86
      58E4A4C3EE452C3D7442536756D4F7041775897C2240C4B437CC97CC5E4270FD
      986DEE9842831B1F233B543F724A9E5B0446BB22CF6C8AC278CD4E275482F61B
      A3461582291443967ED0AA78723A2EBE448AC24726D8EA8F5264BC45A4A7D8B4
      C04EFC7A7271AA361B454EE43365644E5DA9A5F8A5A838D4C93EB6970716B98D
      5617F4E4829E93A816432C9B7621ECF2CB5A75BDD4446F58BC57F1A36215467F
      1722A31FFA2432574F028848A92A0FC5C48C4F391FDF2214429454A6015DD9E6
      496A3B1D5F9768C5326AB2997E038CA5E7E34347D5C5C8E7AE00A9CB48FA4A43
      54768F3C586430B8C4E8C3CAE13EE0265910A0B01FA037CAE333B13B63601397
     Rho (bytes):
      44D2E20D0D57AA501ED3DE916106FF5DA95E4BE2AD4335034F2C757352305980
  X25519 (0x001D)
   x = 0xFB6C61B9A2E5323674FD2C49FA02DF5E1335F52EFBF984C9FC2401F01B1F7C5E

В TLS 1.3 стороны уже на самом первом этапе вычисляют общие секретные ключи, чтобы перейти на защищённый обмен данными. Для этого свою часть открытых ключей (или открытых значений протокола Диффи-Хеллмана, что здесь эквивалентно) должен прислать клиент. Клиент присылает эти ключи в расширении key_share.

В данном случае браузер Chrome прислал нам значение X25519 (внизу) и гибридный набор из X25519 и Kyber768 – то есть, X25519Kyber768draft0 (идентификатор 0x6399 – в начале). Важно не запутаться: криптосистема с постквантовой стойкостью тут одна, она называется Kyber768 (“на научном языке” это KEM – Key Encapsulation Mechanism). Однако в TLS эта криптосистема внедряется в гибридном варианте, то есть, на прицепе к классической, хорошо отработанной, криптосистеме X25519, которая есть разновидность реализации протокола Диффи-Хеллмана. Данный гибрид всё ещё считается “черновым вариантом” – draft. Поэтому полное название X25519Kyber768draft0.

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

Постквантовая часть ключей указана в блоке “Kyber768 client public key”. Ключ Kyber768 состоит из четырёх обособленных значений: это три полинома (Vpoly_N) и параметр Rho. И только лишь ключ Kyber768 занимает уже 1216 байтов. X25519 добавляет лишь 32 байта (в составе гибрида).

Другие элементы расширения key_share, которые тоже отмечены GREASE, это, опять, фиктивные значения, как и в следующем расширении – supported_groups.

 Type: 10 (0x000A); "supported_groups"
  0xAAAA (_undef_ (GREASE))
  0x6399 (X25519Kyber768Draft00)
  0x001D (X25519)
  0x0017 (Secp256r1)
  0x0018 (Secp384r1)

В этом расширении – поддерживаемые клиентом схемы криптосистем. Расширение называется “Поддерживаемые группы” (supported_groups). “Группы” здесь – это технический термин, обозначающий математическую структуру (группу), которая применяется в той или иной криптосистеме (кстати, можно сказать, что “схема”, с математической точки зрения, даже более технический термин, который вполне можно так применить, но, конечно, это лишь случайное совпадение).

Данное расширение всего лишь перечисляет идентификаторы параметров, которые клиент готов использовать. Часть ключей – уже передана в составе key_share. Поэтому тут и присутствуют X25519Kyber768Draft00 и X25519. Однако сервер может не поддерживать ни X25519Kyber768Draft00, ни X25519. В таком случае предстоит выбрать что-то из оставшихся вариантов: Secp256r1 и Secp384r1, под которыми подразумевается протокол Диффи-Хеллмана (DH) на кривых P-256 и P-384. А GREASE – выбрать нельзя. Для перехода к другой криптосистеме сервер, в ответ на CH, отправляет сигнальное сообщение HRR (HelloRetryRequest), указывая в расширениях к нему предпочитаемую криптосистему. Пересогласование криптосистемы для DH поддерживается на тестовом сервере tls13.1d.pw – так что эффект нетрудно увидеть, понажимав Ctrl+F5 (Refresh) в браузере: при пересогласовании клиент пришлёт новое CH, уже с другим составом key_share.

Возникает резонный вопрос: поддержка Kyber768 на серверной стороне не очень-то распространена, нужно ли пересогласование при каждом CH от Chrome с Kyber768? Нет, в типовом случае, серверу не нужно ничего пересогласовывать – сервер может проигнорировать гибридный постквантовый набор и сразу использовать X25519 (поддержка есть практически повсеместно), потому что ключ этой криптосистемы указан в CH от Chrome (не гибридный, а отдельный). Если, конечно, сервер не поддерживает X25519, тогда пересогласовать криптосистему потребуется, но не из-за наличия Kyber768.

Следующее расширение – это фиктивное ECH (Encrypted Client Hello).

 Type: 65037 (0xFE0D); "ECH /DRAFT/"
  Type: 0x00 (Outer)
  HKDF: 0x0001 (HKDF-SHA256)
  AEAD: 0x0001 (AES-128-GCM)
  Config id: 0x04
  Encapsulated key (bytes):
   08FC1E6C6A441874D38689375F9C906827516F2F306BBD8B2376569F99CF0069
  Payload (dummy):
   ECADC2C291D6311FCD925306392EE88CD057D42178C0B60EF5B14814F2CF669E
   05230A0F3D6AABADA0A3EB78D240E22BE2DE5893A50B3AEC4056B77B5CACF7C9
   07F5E6EE853268C23595E22F59E9D190BE9ECCD05B76092CBA00FCCE1C072283
   7CBE371C871817540D8E9429CB10F4CCA3089AB36154D7AE2578FF5D12884F3D
   437AB7A97E0FDA19DCC4B423A4DFD2CF

ECH служит для доступа к скрытым сервисам. Базовое применение: сокрытие имени узла, с которым устанавливается TLS-соединение. Chrome включает фиктивное расширение в CH даже для узлов, которые ECH не объявляли. Это метод придания единообразия TLS-трафику. Расширение ECH устроено довольно сложно, содержит внутри дополнительную структуру и большое по объёму данных поле Payload, которое, в случае фиктивного расширения, имитирует полезные данные ECH (зашифрованное CH). ECH, в данном случае, добавляет ещё 182 байта.

 Type: 00 (0x0000); "server_name"
  00:00:0E:00:00:0B:74:6C:73:31:33:2E:31:64:2E:70:77
  hostname: tls13.1d.pw

Расширение SNI, содержащее имя узла, с которым устанавливается TLS-соединение. Именно данные этого расширения и должно скрывать ECH (в данном случае – ECH не поддерживается). Обычно, это расширение не очень большое по объёму (но зависит от используемого имени).

 Type: 45 (0x002D); "psk_key_exchange_modes"
  01:01
 Type: 17513 (0x4469); /non-TLS-1.3/
  00:03:02:68:32
 Type: 43 (0x002B); "supported_versions"
  0x8A8A (_undef_ (GREASE))
  0x0304 (TLS 1.3)
  0x0303 (TLS 1.2)
 Type: 05 (0x0005); "status_request"
  01:00:00:00:00
 Type: 13 (0x000D); "signature_algorithms"
  00:10:04:03:08:04:04:01:05:03:08:05:05:01:08:06
  06:01
 Type: 11 (0x000B); /non-TLS-1.3/
  01:00
 Type: 27 (0x001B); /non-TLS-1.3/
  02:00:02
 Type: 18 (0x0012); "signed_certificate_timestamp"
 Type: 10794 (0x2A2A); "_undef_ (GREASE)"
  00

Из оставшихся расширений в контексте этой записки интерес представляет только supported_versions (тип 43): в TLS 1.3 именно это расширение содержит настоящий список поддерживаемых клиентом версий TLS. Chrome, помимо очередного GREASE, передаёт здесь идентификаторы версий 1.3 и 1.2. Наличие supported_versions и делает это CH сообщением версии TLS 1.3.

А заканчивается набор расширений всё тем же GREASE.

Итак, на примере конкретного ClientHello хорошо видно, что ключ Kyber768, действительно, занимает основную часть сообщения. Обычный вариант CH, без “постквантовой стойкости”, будет отличаться только отсутствием ключа X25519Kyber768Draft00, всё остальные поля – применяются точно так же.



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

На фото ниже – авиатор Чарльз К. Гамильтон (Charles K. Hamilton) запечатлён в самолёте (аэроплане) “Кёртисс”, начало 20 века. Возможно, даже, что это биплан “Кёртисс №2” (Reims Racer), который Гленн Кёртисс продал Чарльзу (заметьте, не Карлу) Гамильтону, а Чарльз Гамильтон, отличавшийся известной склонностью к авиационным происшествиям, через некоторое время разбил в Сиэтле (в 1910 году).

Hamilton in aircraft

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

Hamilton in aircraft

(Источник фото: LOC.)



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


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

Что касается доменов. В апреле 2024 года домену dxdt.ru – двадцать лет, а домену .ru – тридцать. Домены – часть DNS, а DNS – одна из определяющих черт современного Интернета. Впрочем, происходящие изменения “векторов движения” вокруг этих интернетов, а также и “сдвиг проекций” внутри интернетов (не менее “этих”), не очень располагают к построению оптимистических прогнозов. Можно, впрочем, отметить, что пока и сама Сеть, и многие ресурсы в ней, – всё ещё продолжают работать в глобальном варианте.



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

Кстати, про ноутбуки ASUS Zenbook 14 и линуксы. В свежем ядре Linux 6.8, помимо прочего, исправили дефект, относившийся к воспроизведению звука через встроенные динамики на некоторых моделях упомянутых ноутбуков. Это была распространённая проблема: через выход наушников звук воспроизводился нормально, а через встроенные динамики – нет. А теперь под линуксами с ядром свежей линейки всё заработало. То есть, и новый выпуск Ubuntu LTS (24.04), и, например, Fedora 40, успешно звучат на Zenbook 14 серии UM3402Y в разных вариантах непосредственно через динамики (я проверил на двух ноутбуках – и в комплектации на процессоре Intel, и на процессоре AMD). Не то чтобы для ноутбука это было как-то особенно важно, но всё же.



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