Так-же при diff в YAML будет видно явное различие, у JSON, только если он написан с pretty форматированием, с соблюдением whitespace. у YAML этой проблемы нету, т.к. структура файла изначально определена стандартом.
Это абсолютно неверно. Для YAML это выполняется при тех же условиях: pretty форматирование. Следующие два входных YAML-файла дают один и тот же список из 2 элементов:
- Hello
- World
и
['Hello', 'World']
Чуть сложнее? Пожалуйста:
a:
aa: bb
cc: dd
b:
pp: qq
ss: tt
a:
{aa: bb, cc: dd}
b: {pp: qq,
ss: tt}
В последнем примере отступы сломаны, и ничего. Причём это самые основы, от описанного тут 1.1 vs 1.2 vs 1.2.2 не зависит.
Как известно, любой JSON документ является валидным YAML-документом. С pretty-форматированием или без него, пофиг, он валиден и должен читаться.
С другой стороны, дифф вам может показать различия, которые не имеют значения, в тех же примерах я мог написать aa: bb, а мог "aa" :"bb" и было бы то же самое. Это частая проблема, если меняется версия генератора для автоэкспортёра состояния.
Нет, любой из 5 вариантов деления обеспечивает этот инвариант, по-своему одновременно, но согласованно, определяя операции получения частного и остатка при делении.
если что-то хорошо ложащееся на математику - первый
При этом в GMP есть операция ceiling division специально для редких случаев хотения странного, но базовое у них всё равно T-деление.
Тогда не соизволите объяснить, каким образом ваше мнение должно было учитываться при переходе/не переходе с одного синтаксиса на другой? Для разработчиков Unix в то время.
А это как раз у вас тут образцовая, 300%ная демагогия. Потому что речь не о ситуации, типа, пришёл покупатель земельного участка и вдруг "почему тут сарай? я хотел именно тут пасеку", а продавец, поставивший этот сарай 40 лет назад, не мог представить себе подобного желания.
Нет, аргументы в пользу сохранения порядка аргументов (и вообще синтаксиса в целом) Intel они полностью и безоговорочно были понятны и тогда, и в их принципиальной корректности сомнений не было. А вот почему для конкретной команды исполнителей вес этих аргументов оказался ниже веса аргументов за сохранение того, к чему они привыкли в случае VAX, PDP-11 или, как предположил mpa4b@, M68k, несмотря на потенциальные проблемы при будущем расширении активно развивающейся архитектуры - вот это как раз хороший предмет для исторического исследования. И вот это вы почему-то пытаетесь заткнуть откровенной подтасовкой, типа, что здесь моё мнение, а не аргументация.
Человеку надо тратить умственные силы, чтоб "не засиживаться на месте
Но на что-то полезное. Решение кросвордов, например (пример маргинальный, но показательный) слишком малоэффективно для целей написания программ. Разворот аргументов каждый раз в голове - из этой же серии.
Проблема в том, что вы выше, уже за меня всё решили. Удобнее это мне или нет.
Я за вас ничего не решал. Вы можете для себя переделать любой язык и любой ассемблер как угодно. Посмотрите, например, на ассемблер Go для x86. Он совершенно несовместим ни с Intel, ни с AT&T - там, например, регистр зовётся AX независимо от размера данных в операции. Но его авторы имели свои цели (которые как раз озвучили), и там хотя бы известно, как они описали свои причины. И они не стараются доказать, что это лучший вариант... В случае же AT&T vs. Intel "народная" любовь статистически именно на стороне Intel, и этому причины не только в том, что владелец архитектуры гнёт в эту сторону.
Ну, возможно, да. Просто обычно в источниках пишут, что AT&T синтаксис был взят по аналогии с PDP-11. Я думаю, это уже натяжка, но на этом не акцентировал, а предполагал скорее VAX, на котором таки были образцовые Unix системы по состоянию на 1985. M68k тут как-то побоку, но как источник сомнительных решений типа "cmp p,q это источник флагов согласно q-p" вполне может прокатить...
Довольно странный вопрос. Вы знаете что делает команда cwtl? cwtd?
Пожалуйста, не делайте вид, что не поняли вопрос. Я не про понимание семантики, а про то, как из семантики дальше выводится конкретная буква окончания аббревиатуры. Тут понять невозможно, надо просто запомнить.
то при полном развороте (когда два источника, один приёмник) для синтаксиса AT&T будет достаточно правильно поменять местами именно все операнды, а не какой-то один (но это лишь догадки с моей стороны).
О! Извините, но, вероятно, вы себя тут сами засокра́тили (от имени Сократ). Получается, что синтаксис Intel всё равно исходный, и выяснение вопроса, как правильно, начинается с него... а затем зачем-то развернуть весь порядок.
Ведь в данном случае надо просто последовательно считать значения один за другим, не меняя в дальнейшем их местами.
Для чего именно? Для вычитания всё равно требуются оба аргумента, чтобы начать реальную операцию...
Для AT&T я даже не задумываюсь о том, какое идёт расширение.
Какая логика вам объясняет, когда писать cwtl, а когда - cwtd?
В том, что стали просто буквы использовать, а не полномасштабные команды.
Вы имеете в виду, наверно, указание размера одиночного аргумента в векторных командах. Да, оно там неизбежно, но размер полного набора аргументов по-прежнему определяется регистром. "Полномасштабные команды" это с указаниями типа "dword ptr"? Если нет, уточните.
И я там в последний момент дописал вопрос, вы могли не заметить. Intel:
Как так получилось, что уменьшаемое справа от вычитаемого? Ссылка на историю появления от PDP-11 тут не сработает: у PDP-11, даже, когда в "sub p, q" было вычитание p из q, при этом "cmp p, q" вычитало q из p.
Нам лишь решать использовать этот синтаксис или нет.
Именно. Поэтому, несмотря на то, что GCC и Clang по умолчанию используют AT&T syntax, и в ассемблерных кусках в ядрах и libc всяких Linux и *BSD в основном они - как только мы выходим за пределы этого поддомена, наблюдается существенный разворот в сторону Intel стиля. Я как-то анализировал наличную кодобазу в исходниках, где (в основном во всяком мультимедиа и криптографии) любят ассемблерные файлы.
Если вам этот синтаксис не удобен, то это не значит что он не удобен другим. Все ваши "недочёты", нивелируются человеком который читает код и понимает разницу между синтаксисом AT&T и Intel.
Кто занимается тут игрой слов, вопрос спорный, но я попытаюсь перейти к конструктиву. А он такой, что пропорция тех, кто предпочитает Intel, очень заметная, и за пределами тех, кто исторически с самого начала привык к AT&T, его (AT&T) очень мало хотят.
А с учётом резкого падения части X86 в разработках, где требуется ассемблер, будет падать ещё больше. Держать в голове постоянно выкрутки порядка - сложно.
Все ваши "недочёты", нивелируются человеком который читает код и понимает разницу между синтаксисом AT&T и Intel.
Можно читать не обращая внимание на язык. А можно - обращая, и это полезнее. Потому что от языка может зависеть, например, реакция на целочисленное переполнение, или отличие && в C от and у Паскаля может давать код, который просто так не перенесётся (в любую из сторон).
Недочёты нивелируются, да. Но это лишняя затрата умственных сил, порой резко заметная.
Зачем в очередной раз играть словами?
Я отвечал на ваш вопрос - "зачем перешли", а не "зачем его использовать", "зачем сохранять" и всё такое. Там, где вы видите игру слов, я вижу минимально корректный учёт того, что действительно сказал собеседник. "Игра слов" выглядит иначе.
но вы решили за разработчика что: "он должен делать так как вы сказали"!
Они сами и решают, без меня (см. соседний комментарий). В MIPS, ARM, RISC-V, куче других не только приёмник первый - это не было бы проблемой, если бы единообразно в пределах ISA он был последним - но Unix мир не меняет то, что сделано у соседей. Диверсия введена только для x86 (и, ещё раз повторюсь, не только в плане порядка аргументов). И тем не менее куда ни глянь где nasm, fasm, другие аналоги - Intel порядок тотально.
Логики нет у обоих, но у Intel хоть как-то ровнее. И, повторюсь, названные вами суффиксы не работают:))
Я бы их соответственно назвал: sexti8, sexti16, sexti32, sexto16, sexto32, sexto64 (или альтернативно: sexti ax,al; sexti eax,ax; sexti rax,eax; sexto dx,ax; sexto edx,eax; sexto rdx,rax). Но я тут не решаю.
Странно что вы не жалуетесь на формат команд SIMD-инструкций. Ведь это ближе к AT&T синтаксису, а не Intel.
В чём именно ближе? Вот с ходу из доки Intel:
66 0F 58 /r ADDPD xmm1, xmm2/m128 Add packed double precision floating-point values from xmm2/mem to xmm1 and store result in xmm1.
VEX.128.66.0F.WIG 58 /r VADDPD xmm1,xmm2, xmm3/mem Add packed double precision floating-point values from xmm3/mem to xmm2 and store result in xmm1.
Для меня синтаксис AT&T более удобен. Я к нему быстрее привык, чем к синтаксису Intel.
Попробуйте понять, почему вы думаете, что он вам более удобен. При том, что:
1) Требуется после чтения родных Intel источников каждый раз мысленно разворачивать порядок аргументов. 2) В некоторых случаях требуется делать замены логики в именовании, как в соотношении fsub :: fsubr. 3) Некоторые команды переименованы вопреки всякой логике, причём не получено от этого никакой пользы (ну-тко чем отличается ctlq от clto? Почему вообще не решили назвать как sexto и sexti, чтобы никто не путался?) 4) Порядок аргументов не соответствует подавляющему большинству конкурирующих ISA.
Стоит ли оно того?
Думаю это не нам решать, по какой причине Unix системы остались на синтаксисе AT&T, а не перешли на соседний.
Эээ... вообще-то и нам, и кому угодно. Это не попытка принять решение за других. Это поиск именно исторических причин, в том, что уже состоялось 30-35 лет назад. Вы решили запретить (нам - кому именно нам?) исследовать историю?
Это "недоразумение" существовало и использовалось ещё на PDP11.
Это само по себе не основание для переноса такого порядка на X86, при том, что для MIPS, ARM, RISC-V и прочих тот же gas использует порядок "результат первым".
В данном случае те люди, что сделали порт на 80386 для AT&T V86, заложили диверсию, которую, возможно, сами осознали, но было уже поздно.
Разворачивать все аргументы, а не только переносить приёмник вперёд... для shld, shrd в какой последовательности стоят аргументы - критично для понимания - а тут такая пакость возникла.
Вообще так называемый AT&T syntax, происходящий от прямого переноса логики PDP-11 на X86 ребятами, сделавшими вначале AT&T V86, и что перешло в SCO и затем во все юниксы на X86 - да, штука немного странная. Эффекты не только в порядке аргументов - например, в некоторых командах FPU. Но в реальности достаточно легко привыкаешь.
С точки зрения типов профессионального роста, программисту расти до начальника обычно смысла нет - он растёт квалификационно, в лестнице не поднимаясь выше того же техлида (хотя сколько человек подчиняются его решениям, не определено - могут быть и миллионы).
Зато для QA карьера до тимлида и выше - самое оно: сохраняя принципиальную техническую компетентность, он её только улучшает от такого роста. (Разумеется, если это грамотный разносторонний QA, а не просто тестер.)
Для принятия принципиальных решений вроде какую архитектуру выбрать - у него есть возможность заслушать разных экспертов. Так работает уже давно за пределами IT, где не важно, например, что начальник подразделения может не знать сам какие-нибудь параметры твёрдости конкретной марки стали.
Always call sys_icache_invalidate(::) before you execute the machine instructions on a recently updated memory page.
Вообще, отсутствие автоматической связи здесь и есть если не норма, то по крайней мере то, что надо всегда предполагать. X86 с его TSO и кучей моментов неявной автопомощи программисту здесь исключение (во многом себе во вред) даже для мира CISC.
Сайт сглючил и не дал дописать - что вообще-то вы задаёте вопрос немного не о том. Я в предыдущем комментарии писал не о собственно трекинге зависимостей и что для него нужно, а что кроме этого трекинга должен кто-то понимать, в чём собственно зависимость тех других проектов/компонентов и насколько можно вообще развивать/изменять и в каких направлениях. В такой среде это вполне возможно, хоть и требует постоянной работы со стороны майнтейнеров. А без этого знания легко запланировать какое-то изменение, которое кажется разумным, но будет настолько несовместимо с текущим использованием, что приведёт к форку...
Проще тогда в самом проекте, если он такой важный, перед мерджем PR проверять, что его известные зависимости не ломаются.
Ну вот я и думаю, что это дело CI. Если что-то ломается на его тесте, отправка (push/merge/submit/как_хочешь_назови) не должна проходить (без разрешения кого-то очень важного). А вот как именно CI вычисляет, что зависит, должно поддерживаться как я описал ранее.
А вот это надо решать административными методами. Правило в циркуляре под роспись о том, что введение любой непосредственной зависимости должно хотя бы постфактум порождать тикет об этом, который дальше прорабатывается держателями библиотеки.
Или, если есть указания прямых зависимостей, которые легко ищутся и парсятся, для CI, можно сделать робота, который по изменению этих зависимостей (как в плюс так и в минус) оповещает об этом (и тоже создаёт тикет).
Все средства для этого обычно у команды есть, осталось только интеграции добавить...
У 8086 основная проблема в малом количестве неортогональных регистров. 68k тоже имеет такие проблемы (различие A и D), но не настолько жёстко. 68k значительно ровнее в этом плане. Её проигрыш получился фактически через нерыночные факторы - Intel получил госденьги на OoO архитектуру, Motorola такое не смогла.
С другой стороны, 68k была значительно более стиля CISC чем x86, и, например, декодер и конвертер в микрооперации для него оказался бы значительно дороже, чем даже кошмарик x86. Думаю, при переходе на 64 бита они предпочли бы поменять это полностью, сделав реализацию значительно ближе к RISC (или вообще наложив чужой RISC).
А как bus factor связан с широтой знаний? Если будет 2-3 человека, которые будут знать хотя бы в основе, что зависит от данного компонента и какие могут быть проблемы его изменения?
Мне нужно найти место в текущем коде, а не коммит в истории.
Это если 1) вы реально понимаете, что происходит в текущем коде во всех его аспектах, и 2) это дешевле, чем проба на конкретной версии кода. Оба условия совсем не обязательны. Например, если вы используете чужое API, работа которого отклоняется от документации, или если, как у меня на днях, интерпретатор (PyPy) крэшится под нагрузкой при определённых условиях, надёжно воспроизводимых только на одном кастомере - ничего из простой пробы типа "место в текущем коде" у вас не сработает.
Я же написал - такие, где ошибку можно воспроизвести в отладчике с известными входными данными. Сетевые демоны с большой нагрузкой это один из "необычных" вариантов, но таких проектов единицы.
Ну это, вероятно, у вас единицы. У меня - таких проектов 90+%. А вот такого, где "ошибку можно воспроизвести в отладчике", не наблюдалось уже много лет.
Да, я в курсе, что по относительно свежей статистике 60-70% всех усилий программистов это веб. Ещё заметная часть на мобильные. Но если даже проектов моего типа 5%, это не единицы, это тысячи, если не десятки тысяч...
Это абсолютно неверно. Для YAML это выполняется при тех же условиях: pretty форматирование. Следующие два входных YAML-файла дают один и тот же список из 2 элементов:
и
Чуть сложнее? Пожалуйста:
В последнем примере отступы сломаны, и ничего. Причём это самые основы, от описанного тут 1.1 vs 1.2 vs 1.2.2 не зависит.
Как известно, любой JSON документ является валидным YAML-документом. С pretty-форматированием или без него, пофиг, он валиден и должен читаться.
С другой стороны, дифф вам может показать различия, которые не имеют значения, в тех же примерах я мог написать aa: bb, а мог "aa" :"bb" и было бы то же самое. Это частая проблема, если меняется версия генератора для автоэкспортёра состояния.
Так что советую переуточнить своё представление.
Нет, любой из 5 вариантов деления обеспечивает этот инвариант, по-своему одновременно, но согласованно, определяя операции получения частного и остатка при делении.
При этом в GMP есть операция ceiling division специально для редких случаев хотения странного, но базовое у них всё равно T-деление.
А это как раз у вас тут образцовая, 300%ная демагогия. Потому что речь не о ситуации, типа, пришёл покупатель земельного участка и вдруг "почему тут сарай? я хотел именно тут пасеку", а продавец, поставивший этот сарай 40 лет назад, не мог представить себе подобного желания.
Нет, аргументы в пользу сохранения порядка аргументов (и вообще синтаксиса в целом) Intel они полностью и безоговорочно были понятны и тогда, и в их принципиальной корректности сомнений не было. А вот почему для конкретной команды исполнителей вес этих аргументов оказался ниже веса аргументов за сохранение того, к чему они привыкли в случае VAX, PDP-11 или, как предположил mpa4b@, M68k, несмотря на потенциальные проблемы при будущем расширении активно развивающейся архитектуры - вот это как раз хороший предмет для исторического исследования. И вот это вы почему-то пытаетесь заткнуть откровенной подтасовкой, типа, что здесь моё мнение, а не аргументация.
Но на что-то полезное. Решение кросвордов, например (пример маргинальный, но показательный) слишком малоэффективно для целей написания программ. Разворот аргументов каждый раз в голове - из этой же серии.
Я за вас ничего не решал. Вы можете для себя переделать любой язык и любой ассемблер как угодно. Посмотрите, например, на ассемблер Go для x86. Он совершенно несовместим ни с Intel, ни с AT&T - там, например, регистр зовётся AX независимо от размера данных в операции. Но его авторы имели свои цели (которые как раз озвучили), и там хотя бы известно, как они описали свои причины. И они не стараются доказать, что это лучший вариант... В случае же AT&T vs. Intel "народная" любовь статистически именно на стороне Intel, и этому причины не только в том, что владелец архитектуры гнёт в эту сторону.
Ну, возможно, да. Просто обычно в источниках пишут, что AT&T синтаксис был взят по аналогии с PDP-11. Я думаю, это уже натяжка, но на этом не акцентировал, а предполагал скорее VAX, на котором таки были образцовые Unix системы по состоянию на 1985. M68k тут как-то побоку, но как источник сомнительных решений типа "cmp p,q это источник флагов согласно q-p" вполне может прокатить...
Пожалуйста, не делайте вид, что не поняли вопрос. Я не про понимание семантики, а про то, как из семантики дальше выводится конкретная буква окончания аббревиатуры. Тут понять невозможно, надо просто запомнить.
О! Извините, но, вероятно, вы себя тут сами засокра́тили (от имени Сократ). Получается, что синтаксис Intel всё равно исходный, и выяснение вопроса, как правильно, начинается с него... а затем зачем-то развернуть весь порядок.
Для чего именно? Для вычитания всё равно требуются оба аргумента, чтобы начать реальную операцию...
Какая логика вам объясняет, когда писать cwtl, а когда - cwtd?
Вы имеете в виду, наверно, указание размера одиночного аргумента в векторных командах. Да, оно там неизбежно, но размер полного набора аргументов по-прежнему определяется регистром. "Полномасштабные команды" это с указаниями типа "dword ptr"? Если нет, уточните.
И я там в последний момент дописал вопрос, вы могли не заметить. Intel:
Но AT&T:
Как так получилось, что уменьшаемое справа от вычитаемого? Ссылка на историю появления от PDP-11 тут не сработает: у PDP-11, даже, когда в "sub p, q" было вычитание p из q, при этом "cmp p, q" вычитало q из p.
Именно. Поэтому, несмотря на то, что GCC и Clang по умолчанию используют AT&T syntax, и в ассемблерных кусках в ядрах и libc всяких Linux и *BSD в основном они - как только мы выходим за пределы этого поддомена, наблюдается существенный разворот в сторону Intel стиля. Я как-то анализировал наличную кодобазу в исходниках, где (в основном во всяком мультимедиа и криптографии) любят ассемблерные файлы.
Кто занимается тут игрой слов, вопрос спорный, но я попытаюсь перейти к конструктиву. А он такой, что пропорция тех, кто предпочитает Intel, очень заметная, и за пределами тех, кто исторически с самого начала привык к AT&T, его (AT&T) очень мало хотят.
А с учётом резкого падения части X86 в разработках, где требуется ассемблер, будет падать ещё больше. Держать в голове постоянно выкрутки порядка - сложно.
Можно читать не обращая внимание на язык. А можно - обращая, и это полезнее. Потому что от языка может зависеть, например, реакция на целочисленное переполнение, или отличие && в C от and у Паскаля может давать код, который просто так не перенесётся (в любую из сторон).
Недочёты нивелируются, да. Но это лишняя затрата умственных сил, порой резко заметная.
Я отвечал на ваш вопрос - "зачем перешли", а не "зачем его использовать", "зачем сохранять" и всё такое. Там, где вы видите игру слов, я вижу минимально корректный учёт того, что действительно сказал собеседник. "Игра слов" выглядит иначе.
Они сами и решают, без меня (см. соседний комментарий). В MIPS, ARM, RISC-V, куче других не только приёмник первый - это не было бы проблемой, если бы единообразно в пределах ISA он был последним - но Unix мир не меняет то, что сделано у соседей. Диверсия введена только для x86 (и, ещё раз повторюсь, не только в плане порядка аргументов). И тем не менее куда ни глянь где nasm, fasm, другие аналоги - Intel порядок тотально.
cwtd. Опечатался немного, потому что там логики 0 целых фиг десятых. И вы тут таки неправы:
потому что эта группа команд этим правилам не следует аж никак:
AT&T:
Но Intel:
Логики нет у обоих, но у Intel хоть как-то ровнее. И, повторюсь, названные вами суффиксы не работают:))
Я бы их соответственно назвал: sexti8, sexti16, sexti32, sexto16, sexto32, sexto64 (или альтернативно: sexti ax,al; sexti eax,ax; sexti rax,eax; sexto dx,ax; sexto edx,eax; sexto rdx,rax). Но я тут не решаю.
В чём именно ближе? Вот с ходу из доки Intel:
66 0F 58 /r ADDPD xmm1, xmm2/m128
Add packed double precision floating-point values from xmm2/mem to xmm1 and store result in xmm1.
VEX.128.66.0F.WIG 58 /r VADDPD xmm1,xmm2, xmm3/mem
Add packed double precision floating-point values from xmm3/mem to xmm2 and store result in xmm1.
Приёмник снова первый. Где тут "ближе к AT&T"?
Кстати, вы вспомнили SIMD?
Почему вычитаемое слева от уменьшаемого? ;))
Попробуйте понять, почему вы думаете, что он вам более удобен. При том, что:
1) Требуется после чтения родных Intel источников каждый раз мысленно разворачивать порядок аргументов.
2) В некоторых случаях требуется делать замены логики в именовании, как в соотношении fsub :: fsubr.
3) Некоторые команды переименованы вопреки всякой логике, причём не получено от этого никакой пользы (ну-тко чем отличается ctlq от clto? Почему вообще не решили назвать как sexto и sexti, чтобы никто не путался?)
4) Порядок аргументов не соответствует подавляющему большинству конкурирующих ISA.
Стоит ли оно того?
Эээ... вообще-то и нам, и кому угодно. Это не попытка принять решение за других. Это поиск именно исторических причин, в том, что уже состоялось 30-35 лет назад. Вы решили запретить (нам - кому именно нам?) исследовать историю?
Это само по себе не основание для переноса такого порядка на X86, при том, что для MIPS, ARM, RISC-V и прочих тот же gas использует порядок "результат первым".
В данном случае те люди, что сделали порт на 80386 для AT&T V86, заложили диверсию, которую, возможно, сами осознали, но было уже поздно.
Самая "мякотка" в этой диверсии в ситуациях типа:
Разворачивать все аргументы, а не только переносить приёмник вперёд... для shld, shrd в какой последовательности стоят аргументы - критично для понимания - а тут такая пакость возникла.
Можно включить Intel syntax.
Вообще так называемый AT&T syntax, происходящий от прямого переноса логики PDP-11 на X86 ребятами, сделавшими вначале AT&T V86, и что перешло в SCO и затем во все юниксы на X86 - да, штука немного странная. Эффекты не только в порядке аргументов - например, в некоторых командах FPU. Но в реальности достаточно легко привыкаешь.
С точки зрения типов профессионального роста, программисту расти до начальника обычно смысла нет - он растёт квалификационно, в лестнице не поднимаясь выше того же техлида (хотя сколько человек подчиняются его решениям, не определено - могут быть и миллионы).
Зато для QA карьера до тимлида и выше - самое оно: сохраняя принципиальную техническую компетентность, он её только улучшает от такого роста. (Разумеется, если это грамотный разносторонний QA, а не просто тестер.)
Для принятия принципиальных решений вроде какую архитектуру выбрать - у него есть возможность заслушать разных экспертов. Так работает уже давно за пределами IT, где не важно, например, что начальник подразделения может не знать сам какие-нибудь параметры твёрдости конкретной марки стали.
Вообще, отсутствие автоматической связи здесь и есть если не норма, то по крайней мере то, что надо всегда предполагать. X86 с его TSO и кучей моментов неявной автопомощи программисту здесь исключение (во многом себе во вред) даже для мира CISC.
Сайт сглючил и не дал дописать - что вообще-то вы задаёте вопрос немного не о том. Я в предыдущем комментарии писал не о собственно трекинге зависимостей и что для него нужно, а что кроме этого трекинга должен кто-то понимать, в чём собственно зависимость тех других проектов/компонентов и насколько можно вообще развивать/изменять и в каких направлениях. В такой среде это вполне возможно, хоть и требует постоянной работы со стороны майнтейнеров. А без этого знания легко запланировать какое-то изменение, которое кажется разумным, но будет настолько несовместимо с текущим использованием, что приведёт к форку...
Ну вот я и думаю, что это дело CI. Если что-то ломается на его тесте, отправка (push/merge/submit/как_хочешь_назови) не должна проходить (без разрешения кого-то очень важного). А вот как именно CI вычисляет, что зависит, должно поддерживаться как я описал ранее.
А вот это надо решать административными методами. Правило в циркуляре под роспись о том, что введение любой непосредственной зависимости должно хотя бы постфактум порождать тикет об этом, который дальше прорабатывается держателями библиотеки.
Или, если есть указания прямых зависимостей, которые легко ищутся и парсятся, для CI, можно сделать робота, который по изменению этих зависимостей (как в плюс так и в минус) оповещает об этом (и тоже создаёт тикет).
Все средства для этого обычно у команды есть, осталось только интеграции добавить...
Потому что это действия ровно в противоположном направлении.
Стандарты предусматривают, что в случае необходимости, наоборот, будут забирать секунду, но пока такой необходимости не возникло.
У 8086 основная проблема в малом количестве неортогональных регистров. 68k тоже имеет такие проблемы (различие A и D), но не настолько жёстко. 68k значительно ровнее в этом плане. Её проигрыш получился фактически через нерыночные факторы - Intel получил госденьги на OoO архитектуру, Motorola такое не смогла.
С другой стороны, 68k была значительно более стиля CISC чем x86, и, например, декодер и конвертер в микрооперации для него оказался бы значительно дороже, чем даже кошмарик x86. Думаю, при переходе на 64 бита они предпочли бы поменять это полностью, сделав реализацию значительно ближе к RISC (или вообще наложив чужой RISC).
А как bus factor связан с широтой знаний? Если будет 2-3 человека, которые будут знать хотя бы в основе, что зависит от данного компонента и какие могут быть проблемы его изменения?
Это если 1) вы реально понимаете, что происходит в текущем коде во всех его аспектах, и 2) это дешевле, чем проба на конкретной версии кода. Оба условия совсем не обязательны. Например, если вы используете чужое API, работа которого отклоняется от документации, или если, как у меня на днях, интерпретатор (PyPy) крэшится под нагрузкой при определённых условиях, надёжно воспроизводимых только на одном кастомере - ничего из простой пробы типа "место в текущем коде" у вас не сработает.
Ну это, вероятно, у вас единицы. У меня - таких проектов 90+%. А вот такого, где "ошибку можно воспроизвести в отладчике", не наблюдалось уже много лет.
Да, я в курсе, что по относительно свежей статистике 60-70% всех усилий программистов это веб. Ещё заметная часть на мобильные. Но если даже проектов моего типа 5%, это не единицы, это тысячи, если не десятки тысяч...