В первой версии СНИЛС и так был защищен ключом SK.

Зачем совать UserSecret в H и усложнять себе жизнь? Достаточно было добавить его в V, всё-равно он весь подписывается.

В 3.17 был баг который рушил всё при создании read-only снапшота (исправили в 3.17.2).

Максимальная мощность батареи — 38 КВт/ч.

Да сколько можно? Не мощность, а ёмкость. И не КВт/ч, а КВт*ч

А можно узнать чем можно заменить адресную арифметику? Только без костылей, чтоб было так-же удобно.

В Фортране 77 адресная арифметика эмулируется массивами и equivalence оператором, только программа при этом становится абсолютно нечитаемой.

Да писать можно отлично, а вот читать и отлавливать баги уже не так весело. Объясняю: когда программа связана пачкой слабодокументированных common блоков это плохо, потому что, поменяв что-то в одном месте, нельзя быть уверенным, что не поломал в другом. Бонус: отсутствие проверки типов и возможность назвать сколько угодно разных блоков одним именем, и потом удивляться результату.

Вот отличный пример гениальной программы на Фортране, которую легче переписать с нуля чем понять как она работает code.google.com/p/a-f-d-c/source/browse/trunk/qgraf/qgraf-3.1.2.f

Пример чего, использования common блоков? Достаточно посмотреть на любую более-менее сложную программу на Фортране 77. Объяснять чем плохи common блоки надеюсь не надо.

Единственное отличие Фортрана от C в плане оптимизации в том, что там нет указателей (почти) и автоматически отпадает проблема aliasing. Начиная с C99 есть restricted pointers и можно сделать так же быстро как и в Фортране.

А кто заставляет переписывать? Вопрос был про новый код. А существующие библиотеки никто не запрещает использовать хоть из Python. Хотя и существующее переписывают «почему-то», например ЦЕРН давно перешел с CERNLIB [Fortran] на ROOT [C++].

Популярность Фортрана в науке произошла из того факта, что он простой как три копейки (в варианте 77го года). Можно просто переписать формулу с бумажки и оно начнет считать (FORmula TRANslator всё же). Простота плюс более адекватная работа с комплексными числами — рецепт успеха.

Проблема в том что, что-то более сложное чем формулу с бумажки приходится городить с помощью ужасов типа COMMON blocks и т.д. Это попытались исправить в поздних версиях стандарта, что закономерно всё только усложнило.

Единственное преимущество Фортрана сегодня это скорость компиляции, что удобно для автоматически сгенерированного кода.

Дело не в количестве инструкций, деление и квадратный корень самые медленные арифметические операции с большой задержкой и ограниченной пропускной способностью (14-34 тактов на современных микроархитектурах, на старых ещё больше).

Для отлова простых опечаток можно использовать difflib.get_close_matches

В Yosemite лучше AT&T, но тоже далеко от идеала.

Если защита включена, то для ptrace процесса нужна CAP_SYS_PTRACE capability, которая по-умолчанию есть только у root. Без CAP_SYS_PTRACE можно делать только ptrace child процесса, т.е. gdb ./prog будет работать, а gdb -p PID нет.

Теоретически можно написать launcher с setuid root, который сбросит все права кроме CAP_SYS_PTRACE и запустит нужный процесс. Но мало смысла это делать на уровне пользователя, проще отключить защиту и пользователь сможет делать ptrace любого своего процесса.

Надо писать редхатовацам. Или сусеводам, они как-то моему репорту присвоили CVE, хотя это был всего-лишь DoS крэш.

Скорее всего ядро с CONFIG_SECURITY_YAMA (ptrace_Protection). Надо разрешить ptrace для юзеров

sudo sysctl -w kernel.yama.ptrace_scope=0

Или запускать gdb от root

А GDB грузит символы библиотек? Должен при запуске писать что-то вроде
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6

Я проверил в GDB версий 7.6 и 7.8, одна из них не хотела грузить символы автоматом из командной строки, если писать gdb -p PID. Но gdb -ex "attach PID" работал в обоих.

Можно попробовать запустить просто gdb и ввести команды вручную

> gdb
(gdb) attach PID
(gdb) sharedlibrary .*
(gdb) source /path/pyinject.py
(gdb) set hookfile /path/hook.py
(gdb) pyinject hook open
(gdb) continue

Можно прикинуть на пальцах, считая вакуум фотонным газом и зная плотность реликтового излучения, получается разница в районе 10^-23 миллиметров в год.

Лучше распад нейтрона, а то долго ждать придется)

Одиночные фотоны вполне существуют, а вот плоские волны нет.