one_eight_seven

Для ci комфортно - чтобы тесты проходили минут за 10 (не вся регрессия, разумеется). Иначе, стоит попробовать другие подходы.

И что?

Чтобы "сломать" красивую идею CI не обязательно идти так далеко, как в P&R. RTL тоже сам собой не пишется - это человеческий труд. А CI - это то, как его обложить тестами.

На самом деле странный вопрос. А как вы себе представляете раздельную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил. На находите, что смысл никак не меняется?

Системным вызовом.

Так оттуда и берутся. Иногда поблема разделения труда - не решена. Например, оба добавили свои блоки в общий файл сборки, например, в Makefile. Ну, ещё бывают уникальные снежинки, которые узнали о командах, git: rebase, vommit --amend, push --force, но как работает git, и что делают эти команды - не знают, но имеют жгучую потребность ими пользоваться

Маршрут ci напрямую зависит от инструментов. Я использую Jenkins. От классического ci отличие в том, что коонвейер сборки может ломаться, и будет ломаться, особенно на ранних стадиях проекта. Схема ветвления - все пушат в мастер. Локально можно хоть сотней веток обмазатьмя, но я за это бью по рукам, потому что, если это приводит к "окукливанию" инженера в своей ветке, то это приводит к проблемам интеграции этой ветки в общий маршрут, особенно на ранних стадиях, когда многое меняется. Работать разным людям над одним куском кода - нежелательно, если только это не парное программирование (но оно и не приводит к конфликтам), но иногда это необходимо, хоть я всегда воспринимаю это как сигнал о том, что нужно большее дробление.

Ещё может оказаться, что к серверам СХД подключено через гигабитный ethernet, и всё в него упирается.

А по-другому и не получится, если оставлять МК, питающийся от более,чем 0.9 - 1 В - всегда придётся накачивать ёмкость, и поддерживать её. Проблема туту в том, что 0.5*C*U^2, и "подкачивать" придётся именно верхнюю часть, т.е. самое невыгодное по затратам энергии. Кроме ATTiny, есть MSP430X09X

Опечатка. Разумеется, для RAM нужно `. ram_vectors`

Ядро начинает фетчить команды при старте, начиная с определëнного адреса, и это должен быть ресет вектор, и этот адрес - во флэш. Более того, реализация обработчика ресет вектора - тоже должна быть во флэш. Но можно сделать и так, как вы хотите - разместить всё отладчиком, и отладчиком же установить pc, sp, и работать. Но в реальном использовании это всë сломается, как только произойдëт аппаратный сброс или потеря питания. А как, по-вашему, данные должны попасть в RAM?

Не совсем это пишут. Пишут, что вместо быстрой замены и объединения операций S и L можно использовать кратно большее количество замен в кратно же меньших по объёму таблицах. Но статья написана с ошибками, следовательно, её результаты невозможно проверить. Когда я вижу такое, то сразу бросаю. Поэтому, в своё время я именно с этой статьёй не разбирался. Почему же, ведь далеко не всегда нужно сделать максимально быстро, чаще нужно сделать достаточно быстро. Т.е. если @uriy решит, что уменьшение скорости чуть более, чем вчетверо, по сравнению с методом, использующим 64k, устроит его, то можно помучить немного арифметику.

Так, кузнечик намного требовательнее по вычислительным ресурсам, нежели магма или очень похожий на неë "старый ГОСТ"

Вы можете просто зарезервировать для неë место, и заполнить в рантайме. Она, в любом случае, будет заполняться в рантайме.

Да: LD: startup C file:

И? Первая изначально собиралась верно. Я пишу именно про вторую, релоцированную.

Конечно. Они собрались у вас после текста. Для переноса векторов вам надо создать место для второй таблицы, и при старте скопировать туда основную. Или создать сразу две таблицы, в разных секциях.

Автору нужен RHEL 6, а не RHEL 8.

Есть. Он приведëн в стандарте. Mult table - это предварительно посчитанные результаты объединения L и S функций. Обе функции отдельно описаны в стандарте. Предварительная версия стандарта, если правильно помню, то принят он не был, и послужил материалом для нового стандарта ГОСТ 34.12-2015 (уже заменëн стандартом 34.12-2018).

Да, можно найти centos 6, и натравить на post eol репозитории. Не так давно сам этим занимался. Вроде, оставались записи.

Rocky Linux теперь занимает эту нишу. Организатор - тот же, что в свою время организовал centos. Ещё есть alma. Но вопрос не про то был

А вы купили extended life cycle support? 30 ноября 2020 поддержка rhel6 закончилась

Да, именно так. Наиболее близкий к CTR в этом плане - OFB, там тоже через процедуру шифрования не проходит шифруемое сообщение, а только вектор инициализации, а далее делается XOR результата с текстом. И так же, как в CTR используется только прямая операция и для зашифрования, и для расшифрования. И там термина "гаммирование" не применяется. Есть и другие режимы подобного типа.

Нет. Это не так. Я тот сайт не читал, поэтому, зачем они, на том сайте, смешали два разных понятия, мне неизвестно: стандарт и без этого написан путано и непоследовательно, и не нуждается в дополнительном усложнении. В стандарте такого двойного использования термина "гаммирование"- нет.

Не совсем так. Это процесс зашифрования/расшифрования - XOR открытого/шифртекта с гаммой шифра. Сама же гамма шифра - это зашифрование счëтчика в режиме простой замены (ECB). Таким образом, гамма шифра будет всегда кратна размеру блока. А уже потом, в побитовом XOR, используйте столько бит, сколько нужно.