Нашел на хабре такое:

Также выяснилось что Java в Африке не та же самая Java, и поддержка стойкой криптографии зависит от страны, из-за чего пришлось отложить массовый переход на ECDSA.

Что-то я не совсем понимаю. Допустим что официальная оракловая JVM бывает разной, но никто ж не запрещает взять какой-нибудь IcedTea(openjdk). Или может там какими-то законами запретили ставить жаву, отличную от официальной, так что тогда, в другой стране на Java не заработает Bouncy Castle? https://www.bouncycastle.org/wiki/pages/viewpage.action?pageId=362269 есть там поддержка ECDSA.

А если правительства других стран ЗАПРЕЩАЮТ использовать какие-то алгоритмы шифрования(безотносительно языка программирования), то переписывания алгоритмов с жавы на плюсы ничего не решит - реализация этих алгоритмов на плюсах тоже будет запрещенной.

Какие есть криптографические ограничения в официальных Java VM от оракла для разных стран, и можно ли(законно ли) их обходить через использование Bouncy Castle? И какие есть ограничения на криптоалгоритмы в принципе для разных стран?

Основной вопрос в заглавии. Единственное значимое отличие я увидел в том, что для splice надо чтоб один из файловых дескрипторов был pipe. Получается что sendfile для pipe работать не будет? Если так, почему б не сделать один системный вызов, который бы и к пайпам, и к сокетам, и к обычным файловым дескрипторам был применим?

Есть вообще какие-то правила, которым надо следовать в плане системных вызовов? Например если я свою ОС вздумаю написать, какие системные вызовы лучше делать? Я понимаю что есть какой-то там стандарт POSIX, SUS и проч, где оговариваются какие-то функции, но они могут быть имплементированы в glibc а не непосредственно системными вызовами.

Как в плюсах обстоят дела с метапрограммированием? Например такая задача: есть библиотека длинной арифметики, GMP называется. Даже есть привязка для С++ с перегруженными + - * / и прочими штуками. См https://gmplib.org/manual/C_002b_002b-Interface-General.html#C_002b_002b-Inte...
Так вот, допустим что надо сделать нечто, что делало бы оптимизацию операций с этими вот числами. Пример:

  if (a == 0) error();
  else return (a+a+a+a)/a;

  if (a == 0) error();
  else return 4;

 return a*c+b*c;

 return c*(a+b);

Каким образом в вычислительных устройствах (АЛУ процессора) аппаратно реализован алгоритм умножения? В частности судя по http://www.sm.bmstu.ru/sm5/n4/oba/proz2.html для умножения используются сумматоры и двоичный сдвиг. Я придумал другой метод. Я через дешифраторы преобразовываю двоичную систему счисления в одноединичный код, потом ищу пересечения этих единичек для двух чисел, потом преобразовываю через дешифратор это в двоичную систему счисления. И т.к. умножение это коммутативная операция, схема несколько(почти в два раза) упрощается. Вот нарисовал в logisim http://dump.bitcheese.net/files/umucuby/upd_2.circ и в виде картинки http://dump.bitcheese.net/images/aditoso/sc.png
Имеет ли смысл использовать подобное решение вместо привычного подхода с сумматорами(лучше или хуже оно)? Используется ли подобный подход в процессорах? Если у кого есть опыт с программированием FPGA через verilog/VHDL, имеет ли смысл подобное реализовывать в софт-микропроцессорах? И да, есть ли в Verilog или VHDL cредства для кодогенерации того, что я тут изобразил, для произвольной разрядности чисел? Или надо для таких случаев свой кодогенератор писать? Кастану пожалуй yax123, он вроде что-то на спартанах там делает

Почему современные C/C++ компиляторы не умеют как следует в оптимизацию функций с побочным эффектом? Взять например такой код

#include <inttypes.h>
#include <stdbool.h>

uint32_t test(uint8_t a)
{
  static uint32_t lookup[255] = {0};
  if (a == 0) return 0;
  if (lookup[a-1] != 0 ) return lookup[a-1];
  uint32_t tmp = a;
  tmp = tmp * tmp * tmp * tmp;
  lookup[a-1] = tmp;
  return tmp;
}

bool test2(uint8_t a)
{
  return test(a) == test(a);
}

Так вот, к чему это я. Вопрос: возможно ли как-нибудь «убедить» существующе C(желательно) или на C++(нежелательно) компиляторы, чтобы они мне нормальную мемоизацию делали? Чтобы у меня в данном примере из функции test2 ОДИН РАЗ или вызывалась функция test(записывая или не записывая число в lookup массив) и возвращался 1 или чтобы инлайнил кусок кода из функции лишь единожды, для записи в static массив и чтобы возвращал 1; Я думал насчет того чтобы создать свой язык программирования и «компилировать» его в исходик C и потом его компилить C компилятором, но если компиляторы такие вещи не оптимизируют, мне придется лезть в SSA, LLVM и прочие подобные вещи, а такая перспектива меня не радует

Есть такие вещества, которые обратимо димеризуются с выделением/поглощением тепла. Например N2O4<->NO2. Подобное есть и с большими молекулами, например трифенилметил (свободный радикал) https://upload.wikimedia.org/wikipedia/commons/3/3d/TriphenylmethylRadical.png

А теперь предположим что мы сделали сосуд и поставили посередине некую перегородку, которая пропускает мономер, но не пропускает димер. При этом эта перегородка пропускает мономер в обе стороны. Создать такую перегородку вполне возможно, надо только подобрать два вещества, которые в димеризованном виде не проходят через отверстия в перегородке, а поштучно проходят. Подобные мембраны используются при обратном осмосе. Допустим что мы поставили такую перегородку, разместив изначально все вешество по левую сторону перегородки. Также предположим, что исходное вещество все состоит из димера, при разложении димера на мономеры у нас поглощается тепло, при соединении выделяется ровно столько же. Изначально по обе стороны температура одинакова. Что происходит. Часть димеров слева разлагается на мономеры(температура слева упала), мономеры проходят через перегородку на другую сторону. Да, отлично, но мономеры по другую сторону могут пройти обратно, там опять димеризорваться, и они могут димеризоваться по обе стороны... В конце концов наступит некое равновесие, и температура и концентрация димера-мономера по обе стороны будет одинаково.

Но есть одна уловка. Катализатор. Надо подобрать такое вещество, чтобы без катализатора реакция димеризации и разложения димера на мономеры не протекала, а при наличии - протекала. Катализатор в случае обратимости будет ускорять и прямую и обратную реакцию http://chem21.info/page/066045029122194152101189157037001011231052072031/

Отлично, размешаем катализатор в левой половине сосуда. Ту же левую половину наполняем димером. Обратимая реакция димер<->мономер будет протекать только в одной половине. Спустя какое-то время у нас в правой половине будут только мономеры, в правой будет некое равновесие между димер-мономер. Температура по обе стороны будет одинаковой, так что кажется что тут тоже нет никакого Демона Максвелла. Но нет, он тут как раз есть. Надо лишь поправить условия эксперимента.

В правой половине у нас находятся исключительно мономеры. Температура по обе стороны перегородки аналогична. Опускаем в правую половину катализатор, часть мономеров соединяется в димеры, при этом выделяется тепло. За счет разности температур, используя двигатель Стирлинга, получаем электроэнергию. Только теперь по левую и правую стороны перегородки у нас одинаковое соотношение димера и мономера. Этот димер надо убрать оттуда. Тут все решается очень просто. Поскольку у димера молекулярная масса в 2 раза выше чем у мономера, димер при некоторых заданных условиях будет жидкосью, в то время как мономер - газом. Вместо левой и правой половины, делаем верхнюю и нижнюю половину. В нижней половине катализатор есть всегда. Когда какое-то количество молекул мономера появилось в верхней половине, мы в эту верхнюю половину помещаем катализатор, образуется жидкость, которая просто стекает вниз через отверстие, которое на это время будет открыто. Можно даже извлекать энергию из стекающего вниз димера(это помимо разницы температур).

Получаем такую ситуацию: мономер должен быть газом, димер жидкостью, катализатор должен быть твердым. Внизу лежит пористый катализатор, пропитанный жидким димером Поскольку димер жидкий а мономер газ, можно и без перегородки, паров димера вверху практически не будет т.к. он жидкий при тех условиях. Когда в верхнюю половину сосуда опускаем катализатор, с него начинает капать димер, и поверхность катализатора нагревается т.к. по условию при образовании димера из мономера у нас выделяется тепло.

Вопрос: почему это не будет работать?

Да, именно так. Я не считаю что я опроверг постулаты классической физики, но я не могу понять, почему это не будет работать.

И да, можно и без димеров. Нужно просто два вещества и равновесная A+B<->AB реакция, которая без катализатора не идет, а с катализатором идет, и чтобы A и B были газами, а AB жидкостью при определенных условиях

Есть такой код:

#include <stdio.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <time.h>
#include <errno.h>
#include <sys/types.h>
#include <signal.h>

#define ELF_MAGIC_LE		0x464C457F	/* "\x7FELF" in little endian */

void parent(pid_t);
void child();

int main( int argc, char *argv[])
{
  pid_t pid = fork();
  if (pid)
  {
    parent(pid);
  }
  else
    child();

  return 0;
}

void child()
{
  struct timespec tim = {5,0};
  for(;;) nanosleep(&tim, NULL); //sleep 5 sec
}

void parent(pid_t pid)
{
  size_t i;
  long ret = ptrace(PTRACE_ATTACH, pid, NULL, NULL);
  for (i = 0x0; i+1 < 0xfffff000ULL; i+= 0x1000)
  {
    ret = ptrace(PTRACE_PEEKDATA, pid, (void *)i, NULL);
    if ( ((unsigned long)ret & 0xFFFFFFFF) == ELF_MAGIC_LE) printf ("elf header at 0x%zx\n", i);
  }
  ptrace(PTRACE_DETACH, pid, NULL, NULL);
  kill(pid, SIGKILL);
}

elf header at 0x8048000
elf header at 0x8049000

elf header at 0xf7602000
elf header at 0xf77d7000
elf header at 0xf77d8000

Допустим, нужно проделать много каких-то вычислений, и хочется разбросать их на разные треды. Но одни вычисления зависят от других.

Например если надо посчитать (sin((a+b+c+d)*(e+f+g)))^((a+b+c+d)+(h+i+j)) то можно построить такое дерево:

              (_^_)
               ^ ^
               | |
          +----+ +---+
          |          |
      sin(_)         |
          ^          |
          |          |
        (_*_)      (_+_)
         ^ ^        ^ ^
         | |        | |
    +----+ +-+------+ |
    |        |        |
 (e+f+g) (a+b+c+d) (h+i+j)

Как я себе это представляю:

Надо строить направленный ациклический граф, в каждой вершине храним указатель на следующие вершины(в примере у (a+b+c+d) две следующих вершины: (_*_) и (_+_)); счетчик числа вершин, указывающих на эту вершину, указатель на функцию, которую надо вызвать; массив указателей на данные, которые в эту функцию надо передавать; указатель на область памяти, куда надо записать результат выполнения функции.

Вначале нужно создать очередь, в которую помещаем указатели на те вершины, на которые никакие другие вершины не указывают. Запускаем некоторое количество тредов. По завершени обработки задачи, каждый тред декрементирует счетчик числа вершин в тех вершинах, на которые указывает та вершина, задача из которой была завершена этим тредом(например по завершении (a+b+c+d) надо декрементировать счетчик у вершин (_*_) и (_+_)). Если оказывается что после декрементирования счетчика в только одной вершине оказался 0, тред немедленно приступает к выполнению задачи из той вершины. Если в двух и более счетчиках в вершинах оказался 0, тред добавляет в очередь указатели на все такие вершины, кроме одной, и выполняет задание из той «одной» вершины, которая не добавлена в очередь. Иначе он берет задачу из очереди. Если в очереди ничего нет, тред выставляет особое значение в некоторой переменной, означающее что этот тред бездействует, после чего этот тред сам себе шлет сигнал SIGSTOP. И надо сделать так, чтобы при добавлении задач в очередь, проверялось наличие бездействующих тредов, и слать им сигнал SIGCONT.

Как подобная модель многопоточности называется? Есть ли уже готовые реализации подобного для C или других языков программирования? Через вызов clone() и всякие там CAS спинлоки такое реализовать нетрудно, как мне кажется. Поверх этого можно еще сделать реактивное программирование.

Хочу сделать недоосциллограф из звуковой карты. Я, недолго думая, попробовал подключить к аудиовходу батарейку и записать сигнал через Audacity, посмотреть на результат. Вот что получилось http://dump.bitcheese.net/files/upisadu/battery.flac

После подключения батарейки, звуковуха сначала показывает резкий скачок, но потом оно плавно затухает до нуля, и последующие попытки подключить батарейку ничего не показывают. Если замкнуть контакты, к которым я подключал эту самую батарейку, опять наблюдается скачок, но уже в обратную сторону. (на записи это видно) С чем связана такая особенность работы звуковой карты?

Думаю что если с помощю какой-нибудь микросхемы с достаточно большой частотой менять полярность(или просто замыкать контакты друг с другом), а потом программно инвертировать эти смены полярности на самом компе, проблема решится. Только чем это сделать? Есть какие-нибудь другие предложения?

Допустим, надо воткнуть в устройство некий USB-девайс, при этом чтобы устройство видело этот девайс как обычную USB флешку и могло бы ее подмонтировать и использовать. Но при этом у меня должна быть возможность менять байтики на этой недофлешке через другое устройство. Т.е. такая недофлешка может быть реализована как оперативка, запаянная в какую-то микросхему с двумя male USB проводами, в которую могут записывать одновременно два устройства, которые ее подмонтировали. Или чтобы ПК мог эмулировать сам USB накопитель. Есть уже что-то готовое, или подобное устройство надо с нуля разрабатывать? Как это лучше реализовать?

Допустим, есть устройство на линуксе. К нему есть root доступ, но нужно еще загрузить некий код в ядро и выполнить его там. /dev/mem /dev/kmem и /proc/kcore не работают. Запатчить или подменить ядро в /boot/ тоже не вариант. Какие есть еще способы?

Читал тут код ядра линукс от нефиг делать, набрел на такую функцию двоичного поиска. Алгоритм двоичного поиска печально известен тем, что в нем очень часто делают ошибки https://ru.wikipedia.org/wiki/Двоичный_поиск

Учёный Йон Бентли утверждает, что 90 % студентов, разрабатывая двоичный поиск, забывают учесть какое-либо из этих требований. И даже в код, написанный самим Йоном и ходивший из книги в книгу, вкралась ошибка: код не стоек к переполнениям

http://lxr.free-electrons.com/source/kernel/groups.c#L133

133 int groups_search(const struct group_info *group_info, kgid_t grp)
134 {
135         unsigned int left, right;
...
143                 unsigned int mid = (left+right)/2; <-- вот это вот
...

Задача: экономно упаковать числа в массив, весь диапазон значений которых умещается в число бит, отличное от стандартных 8, 16, 32, 64.

Вопрос: Как подобное правильно реализовать и есть ли уже готовые реализации на C или C++? Ну т.е. понятно что если допустим у нас число из 7 бит и в качестве типа, через который вытаскиваем битики из массива используем 8-битный тип и какое-то число попадает прямо на границу 8-бит, например

01010010001011011000101000010001010000100110110101001010
{-8bit-}{-8bit-}{-8bit-}{-8bit-}{-8bit-}{-8bit-}{-8bit-}
{7bit-}{7bit-}{7bit-}{7bit-}{7bit-}{7bit-}{7bit-}{7bit-}
                                                    ^
                                                    |
                                                 вот это вот

Я тут такую систему счисления придумал, что числа в ней записываются как вектор из степеней простых чисел. Например число 4 будет записано в ней как {2, 0, 0, 0 ...} т.е. как 2^2 * 3^0 * 5^0 * 7^0. Число 6 как {1, 1, 0, 0 ...} т.е. как 2^1 * 3^1 ...

Так вот, наверняка я не первый, кто такое придумал. Как такая система счисления называется и где ее можно использовать? Из очевидных премуществ я вижу то, что умножение, деление в такой системе счисления реализуется через сложение или вычитание двух векторов, а возведение в степень и извлечение корня реализуется как умножение или деление вектора на соответствующее число.

Только вот я не вижу простых путей делать сложение и вычитание чисел в такой системе счисления. Есть ли они?

Существуют ли отладчики под linux, которые бы не использовали ptrace? Например чтобы отлаживать програму без исходников, которая для антиотладки форкается, родительский процесс цепляется к форку через тот самый ptrace() и в рантайме что-то там модифицирует. Как вообще можно реализовать такой отладчик?Для отладки такой штуки надо свой модуль ядра иметь?

Есть какой-нибудь гайд по написанию кода на C таким образом, чтобы он компилировался и корректно работал будучи скомпилированным и плюсовым и С компилятором? В чем там основные несовместимости? Например если надо написать некий код, который надо будет запихивать в устройство, под которое есть только C компилятор, но при этом чтобы было возможным переиспользовать этот код в плюсах, дополнив его плюсовой фигней. На какую версию стандарта C лучше ориентироваться и какие фичи из C отсутствуют в C++?

Может ли само ядро Linux свою собственную память хранить/выгружать в swap раздел во время работы? Если да, как эту возможность включить или выключить и как узнать, включена она или выключена?

Допустим, есть программа, который полностью загружает файл в rwx область и запускает его на выполнение, например таким образом

int main(void)
{
  struct stat st;
  stat("somefile.bin", &st);
  void* ptr = mmap(0, st.st_size,
                   PROT_READ | PROT_WRITE | PROT_EXEC,
                   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  int fd = open("somefile.bin", O_RDONLY);
  read(fd, ptr, st.st_size);
  void (*foo)(void) = ptr;
  foo();
}

Я натыкаюсь на какие-то дурацкие ошибки линкера, вот например если пытаюсь с таким ld-скриптом сделать:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)


SECTIONS
{
  .text 0x0 : AT ( 0 ) {
    *(.text)
    *(.text*)
    *(.init)
    *(.fini)
    *(.rodata)
    *(.data)
    *(.bss)
    *(.ARM.exidx*)
    *(.gnu.linkonce.armexidx.*)
    *(COMMON)
  }
}

$ arm-linux-gnueabihf-gcc-4.8 -static -nostartfiles -Wl,--strip-all,-T ldscript main.c  -O3 -fPIC -o main
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elf.c:4214
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elf.c:4214
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elf.c:4214
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: section .note.gnu.build-id loaded at [0000000000000000,0000000000000023] overlaps section .text loaded at [0000000000000000,00000000000559f7]
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: main: section __libc_freeres_ptrs lma 0x5639c adjusted to 0x563b4
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: .text has both ordered [`.ARM.exidx' in /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/libc.a(mmap.o)] and unordered [`.bss' in /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/libgcc_eh.a(unwind-c.o)] sections
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Можно ли получить информацию, аналогичную получаемой из /proc/self/maps но через какой-нибудь системный вызов? Есть ли кроссплатформенный для unix/unix-like операционных систем способ сделать это?

Линкую вот так

arm-linux-gnueabihf-ld -T ldscript  --oformat binary --strip-all sh.o -o sh.bin

arm-linux-gnueabihf-ld: error: Cannot change output format whilst linking ARM binaries.

ldscript:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
  .text 0x0 : AT ( 0 ) {
    *(.text)
    *(.text*)
  }
}

Объектный файл получаю через

arm-linux-gnueabihf-as sh.S -o sh.o

Код на ассемблере (на всякий случай)

.globl _start

.text

_start:
.rept  10
    nop
.endr

Обычным способом через arm-linux-gnueabihf-ld sh.o -o sh.elf оно вполне линкуется, но я хочу линковать в бинарник своим скриптом. Я конечно могу воспользоваться objcopy, но хочется сделать через ld