LINUX.ORG.RU

Сообщения SZT

 

Моделирование броуновского движения в гравитационном поле

Я тут написал примитивную программу для моделирования броуновского движения, только на целочисленной арифметике, и частица там может ходить по 8 направлениям, как король в шахматах. Т.е. каждый квант времени частица меняет свою координату одним из способов:

[?][?][?]
[?][*][?]
[?][?][?]
и вероятность каждого шага равна 1/8. Если при попытке пойти куда-то частица упирается в стенку, она остается неподвижной на этом шаге симуляции. Гравитация симулируется так: каждый N-тый шаг частица идет на клетку вниз.
[ ][ ][ ]
[ ][*][ ]
[ ][.][ ]
Если внизу есть пол - остается неподвижной,

Загрузил я в этот симулятор шахматного короля такую вот «карту» https://i.imgur.com/u9nnDCS.png c начальными координатами x=3, y=250 (это получается левый нижний угол):

0
 +-----> (x)
 |
 |
 |
 V

(y)
и потом попробовал посмотреть на то, где обычно оказывается координата частицы после длительной симуляции. И вот получается такая картина https://i.imgur.com/NUXtBCo.png

Тут я вывел на график точки, где частица оказывается после такого-то количества шагов. Можно конечно еще какие-то тепловые карты построить, но и так вроде все ясно, вероятность нахождения частицы в нижних секциях этой «лесенки» оказывается ниже, чем в верхних. Если разобраться, получается так, что когда частица попадает в такую вот решетку, которая есть в тех секциях

[#][ ][#][?][#][ ][#]...
[#][ ][#][*][#][ ][#]...
[#][ ][#][?][#][ ][#]...
то идти она может только вверх и вниз, с вероятностью 1/8 вверх, и 1/8 вниз, 6/8 вероятность что она стоит на месте, но при этом гравитация ее толкает вниз, и получается так, что в этих решетках частица опускается быстрее, чем это происходит в пустом пространстве. А насколько это применимо к динамике движения реальных молекул газа или частиц в каких-нибудь коллоидах? Если сделать решетку из каких-нибудь нанотрубок достаточно большого диаметра, и в них залетают молекулы газа, они там тоже будут быстрее падать, чем без них?

Исходники программы могу выложить, если она кому-то интересна.

 , , , ,

SZT
()

Определение лица и температуры по тепловизору и видеокамеры с одноплатника

Мне вот такую задачу подкинули - к одноплатнику на ARM подрубаем две камеры, одна тепловизионная, другая обычная оптическая, и надо чтоб по тепловизионной определять температуру (ну что вот он не болен коронавирусом), а по обычной камере надо делать face recognition чтоб вот прямоугольничек был на лице, и чтоб оператор который смотрит на монитор видел на лице человека, и там бы выводилось над этим прямоугольничком температура, и чтоб еще прямоугольник был красным, если что-то там подозрительное.

Так вот, одноплатник вроде как Jetson Nano предполагается использовать, там есть Cuda. Какие лучше модели для face recognition брать под этот одноплатник, ну чтоб он успевал обрабатывать, там же много людей в кадр попадать могут, надо всем лица определять? Или вот просто взять первую попавшуюся обученную на определение лица нейросеть, и она скорее всего справится?

Ну по поводу детекта температуры с тепловизионной камеры - там наверное просто надо найти максимально теплый участок в пределах прямоугольника определенного для лица - наверняка в OpenCV что-то такое есть, только надо еще и как-то логично совместить изображение с тепловизора и с оптической камеры (ну что вот эти координаты изображения с камеры1 соответствуют вот этим координатам с изображения камеры2) - как это правильно делать и как это вообще называется? Нужно это как-то калибровать?

Может есть уже что-то более-менее готовое опенсорсное под эту скорее всего неоднократно уже решавшуюся задачу?

 , , , ,

SZT
()

Какие есть библиотека для вывода текста для Си, чтоб было похоже на std::cout?

Есть ли какие-нибудь либы для Си, которые б позволяли похожим на cout образом делать вывод, чтоб ставить выводимую переменную в конкретно ту позицию, где я ее хочу вывести, чтоб без этих %d %f и прочего?

Нечто вроде:

uint16_t price = 100;
uint16_t quantity = 15;
my_print(STR, "Price :", UINT16, price, STR, "; quantity:", UINT16, quantity, END);

// аналог std::cout << "Price :" << price << "; quantity:" << quantity;

 , ,

SZT
()

Отправить/получить UDP пакет на каком-то конкретном интерфейсе при полностью одинаковых настройках

Ситуация совершенно гипотетическая. Допустим, есть два интерфейса eth0 и eth1 с полностью аналогичными сетевыми настройками, т.е. и там и там адрес 192.168.0.1, и там и там подсеть та же, даже мак адрес совпадает.
Во-первых, как это вообще настроить?

Во-вторых, допустим я хочу получать UDP пакет с конкретно eth0 интерфейса, в berkeley sockets я не вижу, как это можно было бы сделать. Функция recvfrom() и sendto() принимает структуру struct sockaddr_in в которой sin_addr указывает ip хоста, а конкретный интерфейс указать нельзя! С этим что-то можно сделать? Или только TCP/IP стек в ядре патчить?

 , , ,

SZT
()

Как правильно посчитать HMAC_SHA1 для SRTP пакета?

Мне надо сделать HMAC_SHA1 подпись для SRTP пакета, чтоб через mbedtls либу. Я взял и подсмотрел в либу re в которой есть реализация SRTP и там для SRTP есть HMAC подпись, вот тут:

https://github.com/creytiv/re/blob/05a960b6d633b7f648b7b23b8afc02becbfab157/s...

https://github.com/creytiv/re/blob/38e17f90870c02bed4e50ee883372a1932a4cb67/s...

Попробовал это всё переделать, в общем вот такой код получился

// gcc main.c -lmbedtls -lmbedcrypto

#include <inttypes.h>
#include <stddef.h>
#include <stdbool.h>
#include <string.h>
#include <arpa/inet.h>
#include <errno.h>
#include "mbedtls/aes.h"

#include "mbedtls/md.h"

#include <stdio.h>


//test_srtp_libsrtp
#define AES_BLOCK_SIZE 16
#define MAX_KEYLEN 32
#define SHA_DIGEST_LENGTH 20
#define RTP_VERSION 2

enum aes_mode {
	AES_MODE_CTR,  /**< AES Counter mode (CTR) */
	AES_MODE_GCM,  /**< AES Galois Counter Mode (GCM) */
};

union vect128 {
	uint64_t u64[ 2];
	uint32_t u32[ 4];
	uint16_t u16[ 8];
	uint8_t   u8[16];
};

struct rtp_header {
	uint8_t  ver;       /**< RTP version number     */
	bool     pad;       /**< Padding bit            */
	bool     ext;       /**< Extension bit          */
	uint8_t  cc;        /**< CSRC count             */
	bool     m;         /**< Marker bit             */
	uint8_t  pt;        /**< Payload type           */
	uint16_t seq;       /**< Sequence number        */
	uint32_t ts;        /**< Timestamp              */
	uint32_t ssrc;      /**< Synchronization source */
	uint32_t csrc[16];  /**< Contributing sources   */
	struct {
		uint16_t type;  /**< Defined by profile     */
		uint16_t len;   /**< Number of 32-bit words */
	} x;
};


struct hmac {
	uint8_t key[SHA_DIGEST_LENGTH];
	size_t key_len;
};


struct comp {
//	struct aes *aes;    /**< AES Context                       */
//	enum aes_mode mode; /**< AES encryption mode               */
	mbedtls_aes_context aes;
	
//	struct hmac *hmac;  /**< HMAC Context                      */
	struct hmac hmac;
	union vect128 iv;
	union vect128 k_s;  /**< Derived salting key (14 bytes)    */
	size_t tag_len;     /**< CTR Auth. tag length [bytes]      */
};



static int test_srtp_libsrtp(void);

static int comp_init(struct comp *c, unsigned offs,
		     const uint8_t *key, size_t key_b,
		     const uint8_t *s, size_t s_b,
		     size_t tag_len, bool encrypted, bool hash,
		     enum aes_mode mode);

int srtp_derive(uint8_t *out, size_t out_len, uint8_t label,
		const uint8_t *master_key, size_t key_bytes,
		const uint8_t *master_salt, size_t salt_bytes);


void srtp_iv_calc(union vect128 *iv, const union vect128 *k_s,
		  uint32_t ssrc, uint64_t ix);

int main(void)
{
  test_srtp_libsrtp();
  return 0;
}




/*
 * Reference SRTP-packet generated by libsrtp
 *
 * cipher:       AES-CM-128
 * auth:         HMAC-SHA1 80-bits tag
 * master key:   0x22222222222222222222222222222222
 * master salt:  0x4444444444444444444444444444
 * SSRC:         0x01020304
 * Seq:          0x0001
 * RTP payload:  0xa5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5
 */

/*
static const char *srtp_libsrtp =
	"800000010000000001020304"
	"f5b44b7e3ad4eb057bc6480c45df6547bb70bcc2"
	"7b136e1f3d3a62821b15";
*/

static const char *srtp_payload =
"f5b44b7e3ad4eb057bc6480c45df6547bb70bcc2";
static const char *srtp_hmac =
"7b136e1f3d3a62821b15";

static int test_srtp_libsrtp(void)
{
//	uint8_t pkt[12+20+10];
	uint8_t payload_encr[20];
	uint8_t payload_hash[8];
//	struct srtp *srtp_enc = NULL;
	static const uint8_t mast_key[16+14] =
		"\x22\x22\x22\x22\x22\x22\x22\x22"
		"\x22\x22\x22\x22\x22\x22\x22\x22"
		"\x44\x44\x44\x44\x44\x44\x44"
		"\x44\x44\x44\x44\x44\x44\x44";
	static const uint8_t rtp_payload[20] =
		"\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5"
		"\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5";
	
	struct mbuf *mb;
	struct rtp_header hdr;
	memset(&hdr, 0, sizeof(hdr));
	hdr.ver  = RTP_VERSION;
	hdr.ssrc = 0x01020304;
	hdr.seq  = 0x0001;



//// SRTP alloc

// SRTP_AES_CM_128_HMAC_SHA1_80
	size_t cipher_bytes, salt_bytes, auth_bytes;
//mode = AES_MODE_CTR;

	enum aes_mode mode;
	bool hash;
	const uint8_t *master_salt;

	mode = AES_MODE_CTR;
	cipher_bytes = 16;
	salt_bytes   = 14;
	auth_bytes   = 10;
	hash         = true;

	master_salt = &mast_key[cipher_bytes];

	/*comp_init(&srtp->rtp,  0, key, cipher_bytes,
			 master_salt, salt_bytes, auth_bytes,
			 true, hash, mode);
*/



	struct comp rtp;

	comp_init(&rtp,  0, mast_key, cipher_bytes,
			 master_salt, salt_bytes, auth_bytes,
			 true, hash, mode);
//// end SRTP alloc

	union vect128 iv;
	//uint8_t *p = payload_encr;


	struct srtp_stream *strm;
	uint64_t ix;
	
	//ix = 65536ULL * strm->roc + hdr.seq;
	ix = hdr.seq;

	srtp_iv_calc(&rtp.iv, &rtp.k_s, hdr.ssrc, ix);

	//aes_set_iv(comp->aes, iv.u8);
	//comp.iv = iv;

	size_t nc_off = 0;
	uint8_t stream_block[16] = {0};

	mbedtls_aes_crypt_ctr(&rtp.aes,
		sizeof(payload_encr), &nc_off, rtp.iv.u8,
		stream_block, rtp_payload, payload_encr);

	mbedtls_aes_free( &rtp.aes );

	for(size_t i = 0; i < sizeof(payload_encr); i++)
	{
		printf("%02" PRIx8 "", payload_encr[i]);
	}
	puts("");
	puts(srtp_payload);

	printf("\n-------------\n");


	const mbedtls_md_info_t *md_info = mbedtls_md_info_from_type (MBEDTLS_MD_SHA1);

	unsigned char hmac_sign[20] = {0};

	/// ТУТ КАКАЯ_ТО ПРОБЛЕМА!!!!!!!!!!!!!!
	mbedtls_md_hmac (md_info, rtp.hmac.key, rtp.hmac.key_len,
		payload_encr, sizeof(payload_encr), hmac_sign);


	for(size_t i = 0; i < sizeof(hmac_sign); i++)
	{
		printf("%02" PRIx8 "", hmac_sign[i]);
	}
	puts("");
	puts(srtp_hmac);

	printf("\n-------------\n");

}


static int comp_init(struct comp *c, unsigned offs,
		     const uint8_t *key, size_t key_b,
		     const uint8_t *s, size_t s_b,
		     size_t tag_len, bool encrypted, bool hash,
		     enum aes_mode mode)
{
	uint8_t k_e[MAX_KEYLEN], k_a[SHA_DIGEST_LENGTH];
	int err = 0;

	if (key_b > sizeof(k_e))
		return EINVAL;

	if (tag_len > SHA_DIGEST_LENGTH)
		return EINVAL;

	c->tag_len = tag_len;
	//c->mode = mode;

	err |= srtp_derive(k_e, key_b,       0x00+offs, key, key_b, s, s_b);
	err |= srtp_derive(k_a, sizeof(k_a), 0x01+offs, key, key_b, s, s_b);
	err |= srtp_derive(c->k_s.u8, 14,    0x02+offs, key, key_b, s, s_b);
	if (err)
		return err;

	if (encrypted) {
		mbedtls_aes_init(&c->aes);
		mbedtls_aes_setkey_enc(&c->aes, k_e, key_b*8);
/*		err = aes_alloc(&c->aes, mode, k_e, key_b*8, NULL);
		if (err)
			return err;*/
	}

	if (hash) {
		memcpy(&c->hmac.key, k_a, sizeof(k_a));
		c->hmac.key_len = sizeof(k_a);
		/*err = hmac_create(&c->hmac, HMAC_HASH_SHA1, k_a, sizeof(k_a));
		if (err)
			return err;*/
	}

	return err;
}


int srtp_derive(uint8_t *out, size_t out_len, uint8_t label,
		const uint8_t *master_key, size_t key_bytes,
		const uint8_t *master_salt, size_t salt_bytes)
{
	uint8_t x[AES_BLOCK_SIZE] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
	static const uint8_t null[AES_BLOCK_SIZE * 2];
	//struct aes *aes;
	int err = 0;

	if (!out || !master_key || !master_salt)
		return EINVAL;

	if (out_len > sizeof(null) || salt_bytes > sizeof(x))
		return EINVAL;

	memcpy(x, master_salt, salt_bytes);
	x[7] ^= label;

	/* NOTE: Counter Mode is used for both CTR and GCM */
//	err = aes_alloc(&aes, AES_MODE_CTR, master_key, key_bytes*8, x); TODO
//	if (err)
//		return err;

//	err = aes_encr(aes, out, null, out_len);
	size_t nc_off = 0;

	mbedtls_aes_context aes;
	mbedtls_aes_init(&aes);
	mbedtls_aes_setkey_enc(&aes, master_key, key_bytes*8);

	uint8_t stream_block[16] = {0};

	mbedtls_aes_crypt_ctr(&aes,
		out_len, &nc_off, x,
		stream_block, null, out);

	/*int mbedtls_aes_crypt_ctr( mbedtls_aes_context *ctx,
                       out_len,
                       size_t *nc_off,
                       unsigned char nonce_counter[16],
                       unsigned char stream_block[16],
                       const unsigned char *input,
                       unsigned char *output )*/
	mbedtls_aes_free( &aes );

//	mem_deref(aes); TODO

	return err;

}

void srtp_iv_calc(union vect128 *iv, const union vect128 *k_s,
		  uint32_t ssrc, uint64_t ix)
{
	if (!iv || !k_s)
		return;

	iv->u32[0] = k_s->u32[0];
	iv->u32[1] = k_s->u32[1] ^ htonl(ssrc);
	iv->u32[2] = k_s->u32[2] ^ htonl((uint32_t)(ix>>16));
	iv->u16[6] = k_s->u16[6] ^ htons((uint16_t)ix);
	iv->u16[7] = 0;
}

Я использую функцию mbedtls_md_hmac() но оно выдает не то, что надо. Притом само шифрование сходится. В чем тут может быть проблема, где я напутал?

 , , , ,

SZT
()

refinement type, формальная верификация в нефункцональных языках?

Я вот что подумал - почему вынесенные в заголовок штуки в основном применяются в ФП с жирным рантаймом GC? Это ж вполне можно и в более нормальных языках заюзать.

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

  uint32_t a[100];

  for (size_t i = 0; i < 100; i++)
  {
    if ( scanf("%" SCNu32 "\n", &a[i]) != 1)
    {
      exit(-1);
    }
  }

Вот после этого for цикла (если не произошло exit (-1)) в массиве a[100] образовались какие-то там данные, нам про них ничего в точности неизвестно, там пользователь что попало мог ввести.

Скажем, если мы после этого сделаем такое:

  for (size_t i = 0; i < 100; i++)
  {
    printf("%" PRIu32 "\n", 100500 / a[i]);
  }
То у нас нет гарантии что этот код завершится корректно т.к. в этом a[i] может быть 0 и будет SIGFPE.

А если например перед этим сделать нечто такое

  for (size_t i = 0; i < 100; i++)
  {
    if(a[i] == 0)
    {
      a[i] = 1;
    }
  }
То тогда норм. Вот я хочу, чтобы код в котором может возникнуть ошибка SIGFPE из-за поступления внешних непроверенных данных — вообще не компилировался.

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

Ну и это еще можно использовать для оптимизации, скажем если мы отсортировали некий массив, то потом если мы пытаемся его отсортировать второй раз подряд, то во-первых можно вывести предупреждение от компилятора «этот массив и так сортирован, нечего его сортировать» а во-вторых можно просто вызов сортировки выкинуть т.к. он ничего не делает. Ну и кроме того, есть алгоритмы которым обязательно сортированные данные нужны, например это алгоритм двоичного поиска. Можно на каком-то языке описать, что алгоритм двоичного поиска, если ему на вход подать сортированный массив, он там сможет найти некий элемент если он там точно есть и не найти если его нет. А если ему несортированный массив подать (т.е. для которого нет свойства что a[n] <= a[n+1] для всех n от 0 до размермассива) то тогда это уже неверно, т.е. должна быть ошибка компиляции, если мы не проверенные на сортированность данные пускаем на вход к двоичному поиску

Вообще, есть такой GNU экстеншен __builtin_unreachable() и им можно например такую ерунду вытворять https://godbolt.org/z/dN6ozS

#define ALWAYS_FALSE(a) if(a) __builtin_unreachable()
#define ALWAYS_TRUE(a) ALWAYS_FALSE(!(a))

unsigned div_eq(unsigned a, unsigned b)
{
  ALWAYS_TRUE(a == b);
  ALWAYS_TRUE(a != 0);
  return a/b;
}

unsigned div(unsigned a, unsigned b)
{
  return a/b;
}

Ну и тут вариант div_eq оптимизируется до return 1; (шланг неосиливает) - но это все костыли. И язык аннотаций из Frama-C это тоже костыли - из них такую оптимзацию не сделать, это внешний костыль для проверки контрактов.

Почему нет нормального компилируемого в натив языка без жирного рантайма с GC, чтоб там можно было вот так специфицировать поведение функций, допустимые входные параметры, кванторы-шманторы там, чтоб это все проверялось и оптимизировалось на основе спецификации-контрактов? И чтоб с суперкомпиляцией!

 , refinement type, , ,

SZT
()

Есть ли современный аналог DDD?

Интересует возможность наглядно отображать структуры данных при отладке: http://www.cs.angelo.edu/~mmotl/2305/manual/ddd/html/PICS/ddd-layout.png https://bcaptain.files.wordpress.com/2013/06/ddd.png

Может в каких-то попсовых IDE что-то подобное запилили.

Языки: Си, C++. Всякие хаскели и проч - не интересует.

 , , , ,

SZT
()

Как определить, какому i2c интерфейсу какой hdmi/dvi/vga/dp порт соответствует?

Есть в директории /dev/ такие i2c:

/dev/i2c-0 /dev/i2c-1 /dev/i2c-2 /dev/i2c-3 /dev/i2c-4 /dev/i2c-5

Если вызвать команду xrandr --verbose то там будут перечислены всякие интерфейсы, типа

DVI-I-0 disconnected (normal left inverted right x axis y axis)
...
DVI-I-1 connected primary 1920x1080+0+0 (0x27e) normal (normal left inverted right x axis y axis) 510mm x 287mm
...
DP-0 disconnected (normal left inverted right x axis y axis)
...
HDMI-0 disconnected (normal left inverted right x axis y axis)
...
DP-1 disconnected (normal left inverted right x axis y axis)
...
Каким образом понять, какому из этих DVI-I-0, DVI-I-1, DP-0 и т.д. какой из /dev/i2c-? соответствует? И можно ли это сделать без запущенных иксов?

 , , , ,

SZT
()

Применение FFTW для рисования спектрограммы

Пытаюсь спектрограмму сигнала нарисовать, есть вот такой тестовый код:

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
#include <math.h>
#include <complex.h>
#include <fftw3.h>

#define SQR(x) ((x)*(x))
#define XRESOL 1024
#define YRESOL 768

uint8_t pic[YRESOL][XRESOL] = {0};

#define FFT_CHUNK 512

void fft_calculate(double in[FFT_CHUNK], double complex out[(FFT_CHUNK/2)+1])
{
  fftw_plan p = fftw_plan_dft_r2c_1d(FFT_CHUNK, in, out, FFTW_ESTIMATE | FFTW_PRESERVE_INPUT);
  fftw_execute(p);
  fftw_destroy_plan(p);
}

void convert(double complex in[(FFT_CHUNK/2)+1], double out[(FFT_CHUNK/2)+1])
{
  for (size_t i = 0; i < (FFT_CHUNK/2)+1; i++)
  {
    out[i] = sqrt(SQR(creal(in[i])) + SQR(cimag(in[i])));
  }
}

int main(void)
{
  double arr[XRESOL];
  for (size_t i = 0; i < XRESOL; i++)
  {
    arr[i] =
      sin((double)i * M_2_PI * 0.2)*0.1 +
      sin((double)i * M_2_PI * 0.4)*0.1 +
      sin((double)i * M_2_PI * 0.6)*0.1 +
      sin((double)i * M_2_PI * 0.8)*0.1 +
      sin((double)i * M_2_PI * 1.0)*0.1;
  }
  for (size_t i = 0; i < XRESOL - FFT_CHUNK; i++)
  {
    double complex tmp[(FFT_CHUNK/2)+1];
    double result[(FFT_CHUNK/2)+1];
    fft_calculate(&arr[i], tmp);
    convert(tmp, result);
    for (size_t j = 0; j < (FFT_CHUNK/2)+1; j++)
    {
      #define MULT 10
      pic[j][i] = (result[j] * MULT) > 0xff ? 0xff : (uint8_t)(result[j]* MULT);
      #undef MULT
    }
  }

  fwrite(pic, sizeof(pic), 1, stdout);
  return EXIT_SUCCESS;
}
Собрать-запустить можно вот так:
gcc main.c -lfftw3 -lm
./a.out | display -size 1024x768 -depth 8 gray:-
И оно нарисует пять полосок. Понятно, что в функции fft_calculate() можно переиспользовать план, как указано в этих доках http://www.fftw.org/fftw3_doc/New_002darray-Execute-Functions.html а не создавать каждый раз. Но вот как там с real to real функциями из этого fftw работать? И нужно ли их вообще тут использовать?

Вот эта функция

void convert(double complex in[(FFT_CHUNK/2)+1], double out[(FFT_CHUNK/2)+1])
{
  for (size_t i = 0; i < (FFT_CHUNK/2)+1; i++)
  {
    out[i] = sqrt(SQR(creal(in[i])) + SQR(cimag(in[i])));
  }
}
Правильно ли это? Насколько это вообще корректно? Может тут стоит использовать real to real функции, а не суммировать квадраты действительной и мнимой части, извлпкая потом квадратный корень?

http://www.fftw.org/fftw3_doc/Real_002dto_002dReal-Transforms.html для real to real преобразования там есть параметр fftw_r2r_kind

fftw_plan fftw_plan_r2r_1d(int n, double *in, double *out,
                           fftw_r2r_kind kind, unsigned flags);
Там есть много этих кайндов: http://www.fftw.org/fftw3_doc/Real_002dto_002dReal-Transform-Kinds.html какой из них мне надо использовать? Я попробовал так сделать
void fft_calculate(double in[FFT_CHUNK], double out[FFT_CHUNK])
{
  fftw_plan p = fftw_plan_r2r_1d(FFT_CHUNK, in, out, FFTW_DHT, FFTW_ESTIMATE | FFTW_PRESERVE_INPUT);
  fftw_execute(p);
  fftw_destroy_plan(p);
}
но получилась какая-то ерунда

 , , , ,

SZT
()

Тестирование сетевых программ - имитация плохого соединения

Есть некая программа, которая отправляет UDP пакеты. Мне необходимо в целях тестирования иногда не отправлять ее UDP пакеты, а иногда их дублировать (вместо одного пакета отправим два таких же UDP пакета), или отправлять не в том порядке. И чтобы с входящими UDP пакетами тоже можно было что-то такое делать, т.е. надо имитировать всякие такие проблемы с сетью. Какие для этого существуют опенсорсные решения для Linux?

 , ,

SZT
()

По поводу избирательного применения kpti для разных процессов

Планируется ли впиливать такие костыли в ядро Linux, чтобы некоторые процессы можно было б запускать с запатченным от meltdown механизмом системных вызовов, а некоторые можно было б и с незапатченным?

Обычно память ядра замаплена в адресное пространство процесса, и суть этого meltdown в том, что можно спекулятивно эту память читать, а потом по времени доступа к какой-то другой памяти (из-за кэширования) косвенно определять, что именно прочиталось. И, если я все правильно понял, патч, закрывающий данную дыру, просто отключает маппинг памяти ядра в адресное пространство процесса, оставляя лишь некий минимальный функционал, которого достаточно чтобы опять замапить-размапить ядро в адресное пространство на время исполнения системного вызова. Так почему не сделать так, чтобы запускаемые от имени определенного пользователя процессы работали без этих защитных механизмов? Например, пускать postgresql без kpti, а всякие там браузеры уже с kpti т.к. они выполняют недоверенный код. Опция nopti умеет только глобально эту защиту отключать для всех процессов.

Кроме того, некоторые сервера работают в пространстве ядра, nfs-kernel-server например. Если б можно было легко перенести postgresql в кернелспейс, там будет еще меньше накладных расходов т.к. не надо будет ring0<->ring3 переходов делать, как это происходит с обычными процессами.

Перемещено tailgunner из development

 , , ,

SZT
()

DVB-T2 приставка SRT8500 - можно ли туда поставить Linux?

Есть у меня такая DVB-T2 приставка — SRT8500
SoC там MSD5043, точно какой-то MIPS, видимо MIPS 34K.
Нашел севис мануал: http://www.s-manuals.com/pdf/tv/jiuzhou/jiuzhou_dtt1609_service_manual.pdf
Стоит какой-то модифицированный u-boot (m-boot) https://pastebin.com/6BBhjHS4
и походу они не дают исходники от него: https://lists.denx.de/pipermail/u-boot/2013-September/162519.html

В качестве ОС используется eCos.

Да, так вот, реально ли на этой штуке запустить GNU/Linux и чтоб поддерживался вывод изображения на композитные выходы и на HDMI, чтоб USB завелось? Я к этому SoC даташитов в открытом доступе не нашел. Может уже есть какое-то заточенное под него ядро? Какой там хоть memory map?

Понятное дело, что раз у меня есть доступ к u-boot через uart, я могу грузануть любой код

 , , , ,

SZT
()

Различие в отношении rdtsc и clock_gettime() для разных функций

Проводил я тут сравнение скорости двух функций, которые делают по смыслу одно и то же, но записаны по-разному (одна через таблицу поиска, другая же через кучу if-ов), и там я замерял одновременно время двумя способами, впрочем смотрите сами http://pastebin.ca/3797458

Так вот, отношение величин gettime()/rdtsc() для функции f1 и функции f2 различаются, т.е. если построить по этим значениям график, то получим две полоски. Чем можно объяснить данный эффект?

Запускал я естественно через taskset 0x00000001 и sudo cpufreq-set -c 0 -f 2000MHz, проц Intel Core 2 Quad Q9300 в 64-bit режиме

http://pastebin.ca/3797465 - вывод программы

 , , , ,

SZT
()

Колмогоровская сложность физических констант, сверхтьюринговые вычисления и теоретический предел точности измерений физических констант

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

Но есть и числа принципиально невычислимые, однако им можно дать описание. Скажем, взять какой-нибудь Brainfuck, в котором есть некий фиксированный набор инструкций, возьмем все возможные компьютерные программы на этом самом брайнфаке(их бесконечно) и представим бесконечное число, знаки после запятой в котором в двоичной системе счисления говорят, завершается или не завершается какая-то конкретная программа. Т.е. число 0.10010111011011111011... например говорит о том, что первая программа завершается, вторая и третья не завершается, четвертая завершается, пятая не завершается, в общем как-то так. Так вот, хоть я и смог описать это число, оно не является вычислимым т.к. не существует компьютерной программы, которая бы могла это число сосчитать произвольный знак этого числа т.е. высчитать число со сколь угодно высокой но конечной точностью за конечное время. Можно сказать, у этого числа бесконечная колмогоровская сложность

Так вот, вопрос. Есть ли физические константы, которые можно путем постановки физического эксперимента экспериментально определить со сколь угодно высокой точностью, но при этом чтобы не существовало компьютерной программы для МТ, которая бы могла это число вычислить чисто математическими методами? Взять например два неких радиоактивных изотопа с разными периодами полураспада, и вести наблюдение, какой из них распадется первее. После чего повторить эксперимент с такими же двумя изотопами. При этом, если первым распался один изотоп то записываем 1, иначе 0. Потом, собрав достаточно много такой статистики распада, посмотрим на отношение единиц и нулей. И чем больше проводится подобных экспериментов, тем больше мы получаем точность этого отношения (это будет отношение периодов полураспада, если я все правильно понял). Какие тут будут погрешности в измерениях, есть они вообще, и если да, как их минимизировать/убрать? Существует ли компьютерная программа для МТ, которая могла бы, используя чисто математические/алгоритмические методы, посчитать эту константу? Есть ли вообще такие физические константы, которые при наличии соответствующих ресурсов могут быть вычислены со сколь угодно высокой точностью? Если да, были ли попытки найти некий алгоритм, который бы «сжимал» подобные константы т.е. найти некие закономерности и алгоритм, который бы эту константу считал бы таким же образом, как и число Пи?

Если окажется так, что некие измеряемые константы принципиально «несжимаемы» таким же образом, как является несжимаемым то число проблемой останова, получится что «реальность» может делать какие-то сверхтьюринговые вычисления, и может быть можно путем постановки определенного физического эксперимента найти решение проблемы останова.

 , , ,

SZT
()

Сделать «скриншот» эмулятора терминала с выделябельным текстом и цветами

Хочу делать разноцветные «текстовые скриншоты» из эмулятора терминала, наподобии http://pof.eslack.org/files/2014/04/ssf2xj-radare.png но с выделябельным и раскрашенным текстом, чтоб можно было потом это копировать-вставлять. Неплохим вариантом было б запихивание этого дела в html вместе с цветами и прочим. Надо для вот этой книги в которой про radare2 рассказывается. Может есть какой-то особый эмулятор терминала, который бы позволял делать такого рода скриншоты?

cast XVilka

 , , ,

SZT
()

Ошибка при сборке GCC в crossdev

Скачал я stage3-amd64-20161013.tar.bz2 и portage-latest.tar.bz2, распаковал, сделал туда chroot (все делал по инструкции из https://wiki.gentoo.org/wiki/Chroot/ru, исходная ОС - Ubuntu 14.04.5 LTS если это имеет какое-то значение), установил crossdev и решил вот это сделать:

# crossdev -v -t armv7-none-linux-gnueabi --g 4.9.3 --ov-output /usr/local/portage
Оно успешно собрало бинутилсы, но на этапе сборки GCC произошла ошибка
checking for armv7-none-linux-gnueabi-gcc... /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/ -B/usr/armv7-none-linux-gnueabi/bin/ -B/usr/armv7-none-linux-gnueabi/lib/ -isystem /usr/armv7-none-linux-gnueabi/include -isystem /usr/armv7-none-linux-gnueabi/sys-include   
checking for suffix of object files... configure: error: in `/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/armv7-none-linux-gnueabi/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:9790: recipe for target 'configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build'
Makefile:840: recipe for target 'all' failed
make: *** [all] Error 2
 * ERROR: cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`,
 * the complete build log and the output of `emerge -pqv '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`.
 * The complete build log is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build'
 * S: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-4.9.3'
 * 
 * Please include /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-build-logs.tar.bz2 in your bug report.
 * 

>>> Failed to emerge cross-armv7-none-linux-gnueabi/gcc-4.9.3, Log file:

>>>  '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/build.log'
 * Messages for package cross-armv7-none-linux-gnueabi/gcc-4.9.3:
 * ERROR: cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`,
 * the complete build log and the output of `emerge -pqv '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`.
 * The complete build log is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build'
 * S: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-4.9.3'
 * 
 * Please include /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-build-logs.tar.bz2 in your bug report.
 * 
вот config.log из /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/armv7-none-linux-gnueabi/libgcc/ https://paste.fedoraproject.org/454717/51559147/

Вот конкретно момент, по которому видно, в чем проблема:

conftest.c:1:0: error: target CPU does not support ARM mode
 /* confdefs.h */
 ^
configure:3392: $? = 1
configure:3580: checking for suffix of object files
configure:3602: /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/ -B/usr/armv7-none-linux-gnueabi/bin/ -B/usr/armv7-none-linux-gnueabi/lib/ -isystem /usr/armv7-none-linux-gnueabi/include -isystem /usr/armv7-none-linux-gnueabi/sys-include    -c -g -O2 -pipe  conftest.c >&5
conftest.c:1:0: error: target CPU does not support ARM mode
 /* confdefs.h */
 ^
configure:3606: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3620: error: in `/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/armv7-none-linux-gnueabi/libgcc':
configure:3623: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Там зачем-то проверяется, умеет ли мой процессор запускать ARM бинарники? Он и не обязан это уметь, я собираю кросскомпилятор. Как сделать чтобы crossdev собрал мне GCC который бы создавал бинари под ARM и запускался на x86-64?

Если нужны какие-то дополнительные логи - могу предоставить.

 , , , ,

SZT
()

Написание свободной(Free as in Freedom) книги-самоучителя по программированию: планы, цели, задачи

Итак, я решил написать(или как вариант, собрать из кусочков) книгу-самоучилель по программированию, в которой бы не было глупых и нелепых ограничений на распространение. Однако копилефт я все же считаю приемлемым в данном случае. Общественным достоянием это не будет т.к. вполне могут найтись желающие использовать результат в своих проприетарных книгах, а проприетарные книги — плохо. Лицензия самого текста книги-учебника будет или Creative Commons Attribution-ShareAlike (что позволит без каких-либо проблем переиспользовать текст из википедии) или что-то вроде GNU Free Documentation License (без неизменяемых разделов естественно).

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

Теперь к теме того, на кого книга ориентирована, какие начальные знания предполагаются, чему книга будет учить, какой первый ЯП взять и каков будет авторский самысел: С этим моментом я пока что не определился окончательно, и тут есть что обсудить. В частности, я не вижу особого смысла объяснять какие-то базовые понятия комбинаторики, об этом можно доступным языком прочитать из школьных учебников. Системы счисления(СС), перевод из одной СС в другую - вот это еще можно. One's и two's complement представления знаковых чисел — про это тоже можно написать. Если же человек не понимает комбинаторику, он ее быстро поймет на примере кода, который будет достаточно наглядно это показывать, и который всенепременно будет.
Пока что в качестве первого языка я склоняюсь к Си, и тому есть причины. Все прочие распространенные языки (кроме ассемблера, хотя его трудно назвать распространенным) не настолько близки к аппаратному уровню. Про нужность понимания на низком уровне написано тут http://russian.joelonsoftware.com/Articles/BacktoBasics.html https://habrahabr.ru/company/piter/blog/271347/ , не вижу смысла повторяться. Приведу лишь цитату:

«Просто плохой воркшоп попался», — скажете вы. Но на этом примере я хочу подчеркнуть более масштабную проблему: не изучив для начала C, программист оказывается лишен необходимых орудий, позволяющих понять, что именно происходит в используемой системе. Если вы — умный и пытливый питонщик, то вскоре докопаетесь до плотных пород языка C. Под этими горизонтами, скажут вам, «бойся драконов, костей и отладчиков». Соответственно, если вы не будете достаточно отважны и не проигнорируете предупреждений «да не берись ты за этот C», вы никогда не исследуете глубин, на которые можно забраться просто из любопытства.

Притом еще один важный момент: Си будет изучаться параллельно с ассемблером. Если речь идет об изучении ассемблера, необходимо четко зафиксировать то, на какой архитектуре это все происходит и в какой ОС. Так вот, ОС будет GNU/Linux а архитектура x86-64. Будут постоянно проводиться параллели между тем, что из себя представляет код на Си в текстовом виде, и тем, в какой текст на ассемблере его превращает компилятор. В связи с этим, первым делом будет рассказано о goto и конструкции if(условие) goto метка;. Про конструкции вида

if(условие)
{
  что-то_делаем;
}
else
{
  что-то_другое_делаем;
}
Будет рассказано немного позже, притом это будет рассказано и словами, и через написание эквивалентного кода через if(условие) goto метка;. Циклы, for(){} while{}, do{}while(), конструкция switch-case и break continue внутри них будут так же объясняться через все тот же if(условие) goto метка; притом будет делаться явный акцент на том, что намного лучше использовать нормальные циклы, чем лепить всюду этот условный goto. Кроме того, будет так же рассказано про Labels as Values. Почему так важна эта странная штука, if(условие) goto метка;? Потому что она имеет наипрямейшее отношение к тому, как работают ЭВМ, а всякие циклы СКРЫВАЮТ это. Рекурсия в Си будет объясняться только после того, как будет объяснено, что такое стекфрейм и соглашения вызова, будет сказано про оптимизацию хвостовой рекурсии, и о проблеме забивания стека, если такая оптимизация не происходит, притом это будет наглядно показано в ассемблере. Учиться отлаживать код надо будет тоже «с пеленок», притом отлаживать и ассемблер, и всякие там Си. Будет и про асм-вставки в Си, clobber list. В качестве ассемблера будет рассматриваться GAS, а никакой не NASM т.к. GCC умеет выплевывать ассемблер именно в GAS синтаксисе. Насчет выбора Intel или AT&T синтаксиса - тут я склонюсь пожалуй к тому, что надо ЗНАТЬ И УМЕТЬ ПОНИМАТЬ ОБА. Кроме того, GAS давно уже умеет в оба синтаксиса, так что проблем с этим не будет. Единственная проблема с GAS в том, что это однопроходной ассемблер, так что можно освоить и какой-нибудь NASM, YASM.

Первые хеллоуворды будут написаны вообще в особом стиле, без использования printf() и вообще без библиотеки Си; Будут использованы куски на ассемблере, которые делают системный вызов write и read, и с ними можно(нужно) будет линковаться, чтоб что-то вывести на экран. Будет рассказано и про printf естественно, но только когда будет совершенно четко ясно, что такое вообще va_list. Будет куча отсылок к драфту стандарта Си (недрафт почему-то платный). Будет так же рассказано про устройство ОС. В конце скорее всего будет дано задание сделать свою игрушечную ОС так что предполагается что человек к тому моменту должен уже отлично понимать всякие там связные списки, графы, очереди, спинлоки-аллокаторы свои уметь делать на асме при желании. Алгоритмы сортировки, обхода графов, хеш-таблицы, все это будет объяснено на языке Си, и плюсов вообще касаться я не буду.

Насчет графики: работу с протоколом иксов тоже можно будет рассказать, обработку нажатий клавиши. Правда там надо дофига писать про кучу всего, например что есть сокеты, есть AF_LOCAL... Тогда это можно еще и сетевому программированию учить на каких-нибудь беркли-сокетах.

Кроме того, после моей книги предполагается, что человек должен уметь заниматься такими ненужными (в GNU/Linux) на первый взгляд вещами, как крякинг, реверсинг, исправление ошибок в бинарниках, не обладая исходным текстом. Восстановление логики работы программы по дизасму. Ну и программирование в машинных кодах (без ассемблера, одним HEX редактором).

Как-то уж слишком дофига, не находите? Может быть не надо так глубоко во все это нырять? Жду предложений и критики по поводу того, что нужно, а чего не нужно писать. Возможно что я слишком много хочу.

cast ASM be_nt_all mister_VA

UPD: Программирование и отладка на C/ASM - Первые программы. Знакомство с C и ассемблером. Компиляция, линковка, код возврата. Вывод текста.

 , , ,

SZT
()

Является ли логика первого порядка Тьюринг-полной?

Является ли логика первого порядка Тьюринг-полной? Можно ли описать brainfuck на логике первого порядка?

 , , , ,

SZT
()

Прокрутка(неполная перерисовка) изображения в иксах

Допустим я делаю на xcb нечто графическое, и мне надо прокрутить что-то, например это может быть браузер, и мне надо проскроллить вниз, чтобы прочитать дальше. Или может я делаю сайд-скроллер типа какого-нибудь супермарио, и человечек идет влево, я хочу плавно прокручивать это дело. Мне не хочется на каждый шаг влево перерисовывать всю картинку с нуля (как при событи Expose), я хочу сдвигать уже нарисованный «фон» со всеми врагами, чтоб экономить процессорное время. Каким образом это можно реализовать в xcb? Есть ли там способ сдвигать уже нарисованное куда-нибудь вбок, дорисовывая новое с края? Может для этого мне стоит использовать opengl?

 , , , ,

SZT
()

Не срабатывает нажатие мышкой на 10Выход в эмуляторе терминале

xfce4-terminal 0.6.3, midnight commander 4.8.11

При попытке нажать в нижнем ряду 10Выход при развернутом на весь экран эмуляторе терминала, оно срабатывает так, будто бы я нажимаю 1Помощь

При меньшем размере окна эмулятора терминала, проблемы нет. Это известная проблема, или я наткнулся на какой-то новый баг?

 ,

SZT
()

RSS подписка на новые темы