Метка: программирование

Есть одна статейка, описывающая портирование Unix с PDP-11 на VAX (кстати, вопреки обычно озвучиваемому мнению о легкой переносимости Unix между разными архитектурами, именно продукция фирмы Digital долгое время была основной и практически единственной «платформой» для Unix):

https://www.bell-labs.com/usr/dmr/www/otherports/32v.pdf

На последней страничке приведены пожелания для доработки компилятора, очень интересны пункты 2 и 3:

Based on our experience, we strongly recommend that the C language and its compilers be enhanced so that:
<…>
2. The ’->’ operator is checked to insure that the structure element on the right is a member of a structure to which the pointer on the left may point.
3. A structure element may be declared with any name as long as the name is unique within the immediately surrounding structure. (The current requirement that a structure element name must uniquely correspond to an offset from the beginning of the structure, across all structures in a compilation, creates naming problems and frequently leads to errors of the type noted in item 2 above.)

Написанное немного непонятно для тех, кто никогда не задумывался, как структурки лежат в памяти — поэтому коротенький пример с примером двух ошибок:

struct A {
    int first;
    int second;
};

struct B {
    int first; /* Так нельзя - имена членов структур должны быть уникальны, first уже есть в struct A, см. пункт 3 */
    int second;
};

struct C {
    char c_first;
    int c_second;
};

struct C c;
c.second = 123; /* Компилятор съест и не подавится, но запишет это 123 совсем не туда, куда хотелось бы, см. пункт 2 */
/* То же самое с точки зрения современного Си: */
((struct *A) &c)->second = 123; /* Ты сам себе злобный Буратино */

При этом это поведение, странное с точки зрения «высокоуровневого» программиста и абсолютно нормальное — с точки зрения «низкоуровневой», когда мы думаем о байтиках в памяти, использовалось в коде Unix сплошь и рядом, как подсказывает нам статья, и явно привело к немалому количеству сюрпризов при переходе с 16 бит на 32.

Вот посмотрел я на то, из чего состоит rawStoreBallotTx, передающийся на сервер и сохраняющийся в блокчейн при электронном голосовании в Москве. Разбираться с обширным кодом клиента Exonum на Javascript я не стал, а просто глянул на сами данные.

58 1c c8 b3 ed 95 97 f3 f4 ab c7 76 1d 17 c3 02
a3 d5 3e 59 c8 c7 6c 55 04 4b f0 d3 91 e7 fc c1
00 00 e9 03 06 00 0a 40 64 61 38 35 66 61 66 38
34 66 61 65 62 30 65 39 30 65 66 33 31 61 32 65
37 32 35 32 34 31 35 31 66 62 61 63 30 65 32 66
36 65 36 63 34 39 38 33 36 30 31 33 64 36 34 35
32 39 34 36 39 38 38 64 10 4d 1a 56 0a 14 bc ef
fd 5e 5e a6 8a 6b b2 d9 04 31 dd 51 2e 11 5e 4c
44 e3 12 1a 0a 18 9b 37 cb a5 f0 26 25 ca 74 45
00 21 88 e1 59 ca 56 ee d5 24 dd 25 d3 26 1a 22
0a 20 57 1d b7 6c 24 f5 85 22 7e 75 4c ca e6 97
99 8f f6 22 6b 24 58 94 b9 0d 57 b0 f3 d5 9a 0c
16 01 9d c1 e2 eb 1d 8d 8a cf 12 60 27 3f f0 2e
cc ba 5d 9f 61 e0 ba 51 a7 d2 26 78 82 d1 05 6d
a5 92 93 75 7d 5a c5 23 e0 45 f7 f9 8d 6b ed 4f
33 fe d7 c2 e2 48 77 c6 61 9b 10 86 b3 c7 a7 73 
3f 0d

Первые 32 байта — это некий идентификатор под названием accountAddressBlock; дальше начинается что-то непонятное — но резко выделяется довольно длинная последовательность из байт в диапазоне 30—39 и 60—66 — это цифры и буквы от a до f. Выпишем ее отдельно (справа — символы, которым эти байты соответствуют):

                        64 61 38 35 66 61 66 38            da85faf8
34 66 61 65 62 30 65 39 30 65 66 33 31 61 32 65    4faeb0e90ef31a2e
37 32 35 32 34 31 35 31 66 62 61 63 30 65 32 66    72524151fbac0e2f
36 65 36 63 34 39 38 33 36 30 31 33 64 36 34 35    6e6c49836013d645
32 39 34 36 39 38 38 64                            2946988d

Что это? А это как раз voting id, идентификатор голосования — только зачем-то переданный в виде текста. Сразу же хочется обратить внимание на байт 40, стоящий непосредственно перед voting id — да и вообще на всю последовательность 00 00 e9 03 06 00 0a 40 — хочется считать ее неким заголовком, а 40 — длиной поля. По аналогии находим еще три подобных последовательности — «заголовок» 10 4d 1a 56 0a 14 (в кавычках, и я сейчас объясню, почему) предшествует 20 байтам

                                          bc ef
fd 5e 5e a6 8a 6b b2 d9 04 31 dd 51 2e 11 5e 4c
44 e3

Заголовок 12 1a 0a 18 — последовательности из 24 байт:

                  9b 37 cb a5 f0 26 25 ca 74 45
00 21 88 e1 59 ca 56 ee d5 24 dd 25 d3 26

А заголовок 1a 22 0a 20 — 32 байтам:

      57 1d b7 6c 24 f5 85 22 7e 75 4c ca e6 97
99 8f f6 22 6b 24 58 94 b9 0d 57 b0 f3 d5 9a 0c
16 01

Казалось бы, это вся информация для записи в блокчейн? Но нет — не хватает district id, номера «участка» (здесь он принимал логичные значения 77 и 52 для Москвы и Нижнего Новгорода соответственно). Где он мог потеряться? Оказывается, первый «заголовок» из 6 байт — это на самом деле еще и поле с номером участка, 10 4d (4d в шестнадцатиричной системе — это как раз 77).

В оставшихся 64 байтах я какой-то структуры уже не увидел, но в целом для расшифровки голоса они нам уже не нужны. Вспоминаем структуру данных для передачи — это должны быть зашифрованный голос, nonce и публичный ключ пользователя; в используемой для голосования библиотеке NaCl длина nonce и публичного ключа как раз составляет 24 и 32 байта соответственно, 20 байт — это длина сообщения. Кажется, мы нашли все необходимое? Проверяем несложной программой:

unsigned char message[] = {
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0xbc, 0xef, 0xfd, 0x5e, 0x5e, 0xa6, 0x8a, 0x6b,
    0xb2, 0xd9, 0x04, 0x31, 0xdd, 0x51, 0x2e, 0x11,
    0x5e, 0x4c, 0x44, 0xe3
}; // first 16 bytes must be 0

unsigned char nonce[] = {
    0x9b, 0x37, 0xcb, 0xa5, 0xf0, 0x26, 0x25, 0xca,
    0x74, 0x45, 0x00, 0x21, 0x88, 0xe1, 0x59, 0xca,
    0x56, 0xee, 0xd5, 0x24, 0xdd, 0x25, 0xd3, 0x26
};

unsigned char public_key[] = {
    0x57, 0x1d, 0xb7, 0x6c, 0x24, 0xf5, 0x85, 0x22,
    0x7e, 0x75, 0x4c, 0xca, 0xe6, 0x97, 0x99, 0x8f,
    0xf6, 0x22, 0x6b, 0x24, 0x58, 0x94, 0xb9, 0x0d,
    0x57, 0xb0, 0xf3, 0xd5, 0x9a, 0x0c, 0x16, 0x01
};

unsigned char dit_private_key[] = {
    0xdb, 0x77, 0xd6, 0x2f, 0xc8, 0x87, 0x26, 0xf1,
    0xc5, 0xa6, 0xb7, 0x9b, 0x00, 0x3b, 0x3b, 0xca,
    0x83, 0x34, 0x9e, 0x33, 0x43, 0x37, 0xde, 0x84,
    0xbd, 0x17, 0x34, 0x4a, 0xb6, 0x01, 0xdb, 0x74
};

unsigned char buf[sizeof(message)] = { 0 };

int res, vote;

res = crypto_box_open(buf, message, sizeof(message), nonce, public_key, dit_private_key);
vote = *((int*)(buf + crypto_secretbox_ZEROBYTES));
printf("%x\r\n", vote);

И действительно — расшифрованное сообщение содержит 4 байта 1a d5 be 0d — голос «против» на этом голосовании.

Так вот, возвращаясь к тому, что бесит. Во-первых, бесят просранные талантливыми фронтендерами 32 байта — зачем засовывать voting id в виде строки? Во-вторых — бесит полное отсутствие описание формата передаваемых данных — вот я его разобрал довольно элементарным способом, но пока так и не знаю о назначении еще 64 байт в конце — похоже, что это как-то связано с блокчейном и криптографической подписью для него, но я не уверен.

Боженька, побей их всех по голове ЕСПД.

Вот искал на днях что-то про бенчмарки всяких там ARM-ов, и наткнулся на пару публикаций, где на наглядном примере демонстрируется, что такое — big data, а что — хуйня из-под коня.

Раз (https://inspirehep.net/literature/1424617):

Projects such as the Large Hadron Collider at CERN generate enormous amounts of raw data which presents a serious computing challenge. After planned upgrades in 2022, the data output from the ATLAS Tile Calorimeter will increase by 200 times to over 40 Tb/s.

Два (http://crm-en.ics.org.ru/uploads/crmissues/crm_2015_3/15728.pdf):

The term ”Big Data” has caught on in the mainstream media and science worlds. While this word in now ubiquitous and almost exhausted in it’s use it still identifies an important issue in the science community. Processing data is getting more difficult due to the shear amount being produced. In the year 2022 the ATLAS detector will be upgraded and in doing so will produce in the order of Petabytes per second of raw data [ATLAS C 2012 Letter of Intent…, 2012]. There is no feasible way to process this much data in a reasonable amount of time. This is largely due to external Input/Output (I/O) bottlenecks present in current super computing systems. A team at the University of the Witwatersrand, Johannesburg is actively involved in the development of a computing system which is both cost-effective and able to provide high data throughputs in the order of Gigabits per second. There are four widely accepted computing paradigms. The first, and most commonly known, is the High Performance Computing paradigm (HPC) which is focused on the raw number of calculations performed per second. The second is the Many Task Computing (MTC) which focusses on the number of jobs that can be completed in a given amount of time. Real Time Computing (RTC) involves very strict restrictions on execution times (such as air-bag sensors or process controls). Finally, a fourth paradigm called Data Stream Computing (DSC) involves the processing of large amounts of data with no off-line storage.

Короче говоря, если у вас поток обрабатываемых данных меньше 40 Тб/с, или на одной ноде вы не можете обрабатывать хотя бы несколько Гбит/с — отойдите в сторонку и не мешайте.

Вот пишут, что IBM предлагает бесплатные курсы по изучению COBOL — популярного лет 40 назад языка программирования для всяких бухгалтерских, окологосударственных и прочих «учетных» систем:

https://www.inputmag.com/tech/ibm-will-offer-free-cobol-training-to-address-overloaded-unemployment-systems

Якобы учет безработных в американской службе занятости сделан давным-давно, разумеется, на COBOL, и сейчас из-за массового роста обращений туда требуется эту систему поддерживать, как-то развивать и все такое. В «давным-давно» охотно верится — в брошюре с выставки «Информатика в жизни США» — а это 1987-1988 год, вообще-то! — рассказывается про почти современный уровень компьютеризации (ну с поправкой разве на то, что фронтендеров тридцать лет назад еще не придумали).

Но вот гляжу я на всякие отечественные кривые поделия типа тех же Госуслуг или творчества ДИТа г. Москвы и с ужасом думаю — а что будет с этим через три десятка лет, и что будет тогда вместо COBOL?