В чем смысл определения полных путей для всех команд, но через which? Это карго-культ — в больших кодовых базах на sh в самом деле определяют полные пути к используемым командам, но:
1. либо явно прописывают системный путь, т.е. /bin/ln, /usr/bin/env…
2. либо меняют текущий PATH
У вас ничего из перечисленного не происходит, CMD_CHO etc затрудняют чтение и не добавляют функциональности.
This “student” had created a Verilog design to do not one round of AES encryption, but every round, all in combinatorial logic with no clocks in between.
Перевод:
этот студент создал Verilog-схему, в которой AES-шифрование выполняется в течение не одного раунда, а каждый раунд, с комбинаторной логикой без тактов.
Имеется в виду, что все операции происходили без разделения на шаги (раунды), в одном раунде. Вот зачем такой перевод? Просто бросили бы ссылку на оригинал.
А бывают услуги наподобие HDD до 1Tb, scp или ftp over ssl access? Никаких хостингов сайтов, ни баз данных, ни VPS, просто online место под storage. Возможно, лимитирование трафика или какой-то тариф.
AWS S3 или tarsnap.com несколько не то, yandex disk/onedrive/dropbox совсем не то.
bluespec относительно используемый промышленный язык, основанный на haskell. На нем, например, написана BERI — реализация MIPS архитектуры, и ее расширение CHERI.
Нет, проблема общая и для brk() и для sbrk(): нужно знать текущий _end, согласованный с результатом вызова. brk() принимает новый _end как аргумент, sbrk() — инкремент, но проблему то это не решает. Посмотрите, что будет, если другая нитка вклинится между чтением _end и вызовом. Проблема интерфейса, а не реализации, разве что musl ее в самом деле решил окончательно.
Современные GC аллокаторы, кстати, устроены похоже, но у них такая область своя для каждой нитки.
sbrk не рекомендуют пользоваться, потому что у sbrk может быть только один пользователь. Посмотрите на интерфейс — void *sbrk(intptr_t inc), т.е. вы должны знать текущий конец сегмента sbrk, который после аллокации станет началом выделнного куска памяти. Если вы и malloc из libc станут оба звать sbrk, не обновляя значение конца сегмента друг другу, затрется чужая память.
Эта же проблема влияет и на многопоточный malloc(), если две нитки одновременно захотели получить куски памяти от системы, то они должны сериализоваться, чтобы не затереть значение конца сегмента.
Поэтому новые реализации malloc предпочитают mmap, например jemalloc. Единственная видимая проблема от использования mmap — не работающий RLIMIT_DATA.
1. либо явно прописывают системный путь, т.е. /bin/ln, /usr/bin/env…
2. либо меняют текущий PATH
У вас ничего из перечисленного не происходит, CMD_CHO etc затрудняют чтение и не добавляют функциональности.
Перевод:
Имеется в виду, что все операции происходили без разделения на шаги (раунды), в одном раунде. Вот зачем такой перевод? Просто бросили бы ссылку на оригинал.
AWS S3 или tarsnap.com несколько не то, yandex disk/onedrive/dropbox совсем не то.
И x86 процессоров, которые поддерживают cmpxchg, но не умеют xadd, не бывает. Обе инструкции появились в 486.
xorl %edi, %edi
гарантированно обнуляет %rdi, потому что в IA32 поведение 32битных инструкций в long mode — zero extend.
Современные GC аллокаторы, кстати, устроены похоже, но у них такая область своя для каждой нитки.
Эта же проблема влияет и на многопоточный malloc(), если две нитки одновременно захотели получить куски памяти от системы, то они должны сериализоваться, чтобы не затереть значение конца сегмента.
Поэтому новые реализации malloc предпочитают mmap, например jemalloc. Единственная видимая проблема от использования mmap — не работающий RLIMIT_DATA.