Это заговор
Dec. 4th, 2009 09:59 pmЧеловеку для определения чего-то естественно последовательно уточнять, а не наоборот. Город, улица, дом, квартира. Или час, минута, секунда. Или сотни, десятки, единицы. В общем, оно понятно.
При этом некоторые пишут/читают слева направо, некоторые справа налево, как у кого повелось, тут "интуитивно понятного" нет, это традиция, как есть страны с левосторонним и правосторонним движением. Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.
Так вот. Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево? Почему не ua.kiev.firma (как в иерархии конференций usenet, в фидошных эхах и во многих других местах)? Кто из авторов DNS был евреем или арабом? Ведь даже для резолвинга разбирать домен нужно последовательно справа налево (сначала ua, потом kiev.ua, потом firma.kiev.ua), что совершенно нелогично для английского языка.
Я уже молчу про интеловскую архитектуру с хранением чисел "левый байт самый младший" - такой записи нет ни у евреев, ни у арабов, насколько я знаю. И ведь каждый раз при приёме или отправке таких чисел в сеть нужно переставлять байты местами, а при получении - менять обратно, потому что в сети, благо, принят нормальный порядок (сначала старший байт, потом младший). В чём же фишка перевёрнутого порядка байт? Чтобы можно было записать четырёхбайтное число, а потом по тому же адресу прочитать двухбайтное, и, если число было небольшим, получить правильный результат? Как-то это несолидно выглядит в качестве аргумента.
При этом некоторые пишут/читают слева направо, некоторые справа налево, как у кого повелось, тут "интуитивно понятного" нет, это традиция, как есть страны с левосторонним и правосторонним движением. Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.
Так вот. Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево? Почему не ua.kiev.firma (как в иерархии конференций usenet, в фидошных эхах и во многих других местах)? Кто из авторов DNS был евреем или арабом? Ведь даже для резолвинга разбирать домен нужно последовательно справа налево (сначала ua, потом kiev.ua, потом firma.kiev.ua), что совершенно нелогично для английского языка.
Я уже молчу про интеловскую архитектуру с хранением чисел "левый байт самый младший" - такой записи нет ни у евреев, ни у арабов, насколько я знаю. И ведь каждый раз при приёме или отправке таких чисел в сеть нужно переставлять байты местами, а при получении - менять обратно, потому что в сети, благо, принят нормальный порядок (сначала старший байт, потом младший). В чём же фишка перевёрнутого порядка байт? Чтобы можно было записать четырёхбайтное число, а потом по тому же адресу прочитать двухбайтное, и, если число было небольшим, получить правильный результат? Как-то это несолидно выглядит в качестве аргумента.
no subject
Date: 2009-12-15 12:13 pm (UTC)При этом некоторые пишут/читают слева направо, некоторые справа налево, как у кого повелось, тут "интуитивно понятного" нет, это традиция, как есть страны с левосторонним и правосторонним движением. Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.
Так вот. Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево? Почему не ua.kiev.firma (как в иерархии конференций usenet, в фидошных эхах и во многих других местах)? Кто из авторов DNS был евреем или арабом? Ведь даже для резолвинга разбирать домен нужно последовательно справа налево (сначала ua, потом kiev.ua, потом firma.kiev.ua), что совершенно нелогично для английского языка.
Но, заметим, в английской традиции если я живу в квартире X дома Y улицы Z города N страны M, мой адрес будет записываться как
X/Y Z Street, N M (X/Y Z street, Sydney, Australia)
Так что как раз DNS и email выглядят очень логично.
no subject
Date: 2010-03-08 05:30 pm (UTC)Вообще-то Little Endian происходит от алгоритма сложения...
ADC (R0)+,(R1)+
no subject
Date: 2010-03-08 06:25 pm (UTC)> ADC (R0)+,(R1)+
На какой архитектуре был выигрыш от обратного порядка байт?
От кого это пошло?
Откуда, вообще, информация, что это от сложения? Когда взять сначала первый байт, а потом второй, быстрее, чем наоборот?
no subject
Date: 2010-03-08 06:52 pm (UTC)Т.е. его надо было рисовать или как NEG, INC, NEG или как ADI #-1, это длиннее и дольше (кэша не было, память медленная).
Бывает команда IJNZ, с ней используется _отрицательный_ счетчик цикла...
Поэтому автоинкремент кажется как-то привычнее автодекремента.
Вообще, иногда оптимальный XOR записывается как
a + b - ((a & b) << 1) ;-)
no subject
Date: 2010-03-08 09:38 pm (UTC)Но зачем так хранить данные там, где это от этого нет выигрыша в эффективности арифметики (а проигрыш от перестановок туда-сюда довольно существенен)?
Internet
Date: 2010-03-08 09:49 pm (UTC)А значит, оба варианта были равноправны.
Интернет сделал IBM/Motorola/Sparc "равнее" чем DEC/Intel.
Кстати, кажется, DCE RPC (Microsoft DCOM) использует little endian...
no subject
Date: 2010-06-07 09:18 pm (UTC)Съездил в Киев 7-го.
Съездил в Киев 7-го июня.
Съездил в Киев 7-го июня 2010 года.
Съездил в Киев 7-го июня 2010 года нашей эры.
> Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.
Говорят все одинаково - одни слова раньше, другие позже.
Вот числа арабы пишут как бы начиная с младшей цифры: запись числа графически выглядит для нас и для них одинаково при противоположных направлениях. В Liber Abaci и вслед за ней аж до Магницкого "арабские" цифры упоминались в порядке от 9 до 1, а не от 1 до 9.
Это не оправдание, но факт противоположный твоему описанию.
> Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево?
Наверно, надо обратиться к первоисточникам? Спускаемся до RFC805:
These basically involved adding more hierarchical name information
either to the right or the left of the @, with the "higher order"
portion rightmost or leftmost. It was clear that the information
content of all these syntactic alternatives was the same, so that
the one causing least difficulty for existing systems should be
chosen. Hence it was decided to add all new information on the
right of the @ sign, leaving the "user" field to the left
completely to each system to determine (in particular to avoid the
problem that some systems already use dot (.) internally as part
of user names).
То есть:
1. Первым фактором, повлиявшим на порядок частей, является то, что к тому времени уже существовала форма user@host, пусть и с одночастным хостом. В свою очередь (это уже по следам чтений других ранних RFC) началось с этапа, когда user было важнее host, поэтому оно на первом месте.
2. Расширение уточнением справа соответствовало логике объединения разных сетей, то есть меньше было изменений в местном имени по сравнению с полным. То есть, pete@foo.bar == pete@foo в сети bar, а не pete@bar в сети foo.
3. Разумеется, всё это было неявно подкреплено англосаксонской традицией начинать адреса с наиболее частных частей. Здесь можно много растечься, например, о связи этой традиции со стилем законодательства и вообще методов "оформления жизни", но достаточно вспомнить, что нормальный человек обычно думает о себе и близких начиная с наиболее локальных адресных пространств (квартира, дом, улица, город).
По-моему, достаточно логичный результат.
Кстати, ещё пример на ту же тему из X.509 guide - X.500 порядок (от глобального к локальному) противоречит LDAP порядку (от локального к глобальному).
(TBC)
no subject
Date: 2010-06-08 07:34 am (UTC)Если глобальную часть можно отбросить, и это будет означать нечто подразумеваемое, тогда начинают с наиболее значимой, локальной части. Например, "съездил в Киев 7-го" (без уточнения месяц и год подразумеваются), или "выключи духовку без десяти" (час подразумевается).
То же и с доменами: по умолчанию добавляется локальный суффикс, поэтому, если суффикс не локальный, он добавляется в конце. А резолвинг сделали в обратную сторону - не поднимаясь по иерархии неймсерверов от локального, а опускаясь сразу от корня - так оказалось проще.
Если же вся информация важна (и час, и минута, и секунда), тогда начинают с наиболее глобальной (потому что локальная часть без глобальной в этом случае лишена смысла).
Правда, из этого правила тоже много исключений. Например, телефонный номер - по умолчанию локальный, но для нелокальных код добавляется в начале, а не в конце.
no subject
Date: 2010-06-07 09:19 pm (UTC)Никто, и даже странно такое предположение слышать. Вот именно, что араб бы точно начал с глобальной части. Насчёт евреев не скажу - тут всё сложно.
> Я уже молчу про интеловскую архитектуру с хранением чисел "левый байт самый младший" - такой записи нет ни у евреев, ни у арабов, насколько я знаю.
Ха тире ха. Они именно так и воспринимают, см. выше:) только не "левый" а "раньше всего встречающийся (при разбора написанного)". Но это опять-таки не становится причиной такой реализации.
> В чём же фишка перевёрнутого порядка байт? Чтобы можно было записать четырёхбайтное число, а потом по тому же адресу прочитать двухбайтное, и, если число было небольшим, получить правильный результат? Как-то это несолидно выглядит в качестве аргумента.
Ты статью в википедии читал? Вот ещё аргумент:
Little-endian representation simplifies hardware in small-scale byte-addressable processors and microcontrollers: As carry propagation must start at the least significant byte, multi-byte addition can then be carried out with a monotonic incrementing address sequence, a simple operation already present in hardware.
(skolk говорил то же, но своими словами)
Если помнишь:), в 1964-м с появлением S/360 возникла концепция "тотальной двоичной иерархии" (все размеры - степени двойки). Но S/360 - big-endian. А PDP-11 - little-endian. Вот и начался разнобой...
no subject
Date: 2010-06-07 09:35 pm (UTC)Ты много внимания уделяешь некоторым базовым концепциям мышления. Это вполне логично, но в массе случаев они перекрываются обучением, традициями, совместимостью и так далее.
Думаю, авторы PDP-11, которая, похоже, первой показала little endian порядок (более ранних примеров я пока не нашёл) - могли видеть обратный порядок где-то в недрах прошлых установок. А, может, и не видели, но во всяком случае он их не настолько смутил, чтобы отказаться от пользы от него. И так, пожалуй, ко всем твоим примерам: есть масса причин возникновения таких странных порядков, одни сильнее, другие слабее, но для кого-то они оказались решающими.