Почему не работает ping?

покажи вывод ip addr и ip route

Почему не работает ping?

One2Three, ок, тогда разумно было бы интерфейсу eth0 дать адрес из подсети 192.168.0.0/24, после чего заработает ip route add default via 192.168.0.1

Почему не работает ping?

Ты так и не ответил где у тебя маршрутизатор.

при выполнении ip route add default via 192.168.0.1 возникает ошибка

А зачем ты это делаешь, если маршрутизатор у тебя, предположительно, на 192.168.1.1?

Почему не работает ping?

default via 192.168.1.1

и у тебя на 192.168.1.1 есть маршрутизатор? 192.168.1.1 пингуется?

src 192.168.1.10

вот тут тоже какая-то фигня, должно бы быть 192.168.1.2

Почему не работает ping?

One2Three, покажи вывод ip route

Почему не работает ping?

lo: <LOOPBACK>

Этот интерфейс не активен (down).

PING 192.168.0.1

Этот адрес требует маршрутизации, как и 8.8.8.8, похоже с ней не всё в порядке.

Как убрать пробел из алиаса?

Как убрать добавляемый пробел в конце?

Это тот самый пробел, который отделяет c от Filter в командной строке которую ты вводишь. Никак его не убрать при таком подходе.

Почему при одновременном подключения tft spi 1.8 и mfrc522 экран при обновлении мерцает белым?

Брать шинный анализатор или осциллограф и смотреть, что происходит с линией CS идущей к дисплею.

Как написать свой драйвер под Windows на fasm?

Как написать свой драйвер под Windows

Взять существующий из DDK, понять как он работает и поправить под свои требования.

на fasm?

Хоть на брейнфаке.

Адрес в макросе?

Адреса функции известны ещё на этапе компиляции

Василий Банников, на этапе линковки. И только если линкуется не-PIE исполняемый файл. И только для функций из этого же исполняемого файла. В противном случае -- нет, адреса функций неизвестны до того момента, пока динамический линковщик (или стаб встроенный в PIE) не вычислит их не не запишет в GOT.

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

Мне нужно считывать из файла строки с пробелами, оканчивающиеся символом переноса

Qubc, можно использовать scanf("%[^\n] ", str); (заметь пробел после форматной строки, извлекающий символ конца строки на котором остановился матчинг), и знать, что строка считана в str, но конец строки в неё не попал.

Как git изменяет содержимое файла?

Но, точно "Полные копии всех состояний не хранятся".

Vitsliputsli, слушай, ну с чем ты споришь, если можно просто взять и убедиться, что по умолчанию хранятся?:

$ git init .
$ hexdump -Cv /dev/urandom | head -n 100000 > a
$ stat a
  File: a
  Size: 7900000         Blocks: 15432      IO Block: 4096   regular file

Вот подопытный файл размером почти 8M.

$ git add a
$ git commit -m 'version 1'
[master (root-commit) b36ee5cb126b] version 1
 1 file changed, 100000 insertions(+)
 create mode 100644 a
$ git cat-file -p b36ee5cb126b
tree f5870cee82fda72446a4dd3be8ebaeffe46035a3
author <[e-mail]> 1679909736 -0700
committer <[e-mail]> 1679909736 -0700

version 1
$ git cat-file -p f5870cee82fda72446a4dd3be8ebaeffe46035a3
100644 blob 65a9d4359a613ac58723324b2da83294673ca018    a
$ stat .git/objects/65/a9d4359a613ac58723324b2da83294673ca018 
  File: .git/objects/65/a9d4359a613ac58723324b2da83294673ca018
  Size: 4090218         Blocks: 7992       IO Block: 4096   regular file

Вот файл блоба с его первоначальным состоянием размером 4М.

$ echo 'some more data' >> a
$ git commit -a -m 'version 2'
[master 73e8c999ed23] version 2
 1 file changed, 1 insertion(+)

Вот к нему добавилась одна строчка

$ git cat-file -p 73e8c999ed23
tree 57ce1455664bd5027552860b713779c226c70fe9
parent b36ee5cb126b84100984c5b44f6d1f39155bd747
author <[e-mail]> 1679909809 -0700
committer <[e-mail]> 1679909809 -0700

version 2
$ git cat-file -p 57ce1455664bd5027552860b713779c226c70fe9
100644 blob 22f30336c84a6f20376a83fc04977797969f80b4    a
$ stat .git/objects/22/f30336c84a6f20376a83fc04977797969f80b4 
  File: .git/objects/22/f30336c84a6f20376a83fc04977797969f80b4
  Size: 4090233         Blocks: 7992       IO Block: 4096   regular file

Вот ещё один файл блоба, из нового коммита, с добавленной одной строчкой, почти такого же размера -- 4M.

В эту игру можно играть целый день:

$ for a in `seq 3 100` ; do echo 'some more data' >> a ; git commit -a -m "version $a" ; done
...
$ du -sh .git/objects/
392M    .git/objects/

100 коммитов с блобами по 4М, а каждый коммит только по одной строчке в конец добавил.

Как git изменяет содержимое файла?

например мой реп в 30Мб

Vitsliputsli, anecdotal evidence такой anecdotal evidence.

Как git изменяет содержимое файла?

по данной вами же ссылке написано

Vitsliputsli, точная цитата такая:

Первоначальный формат для сохранения объектов в Git называется «рыхлым» форматом (loose format). Однако, время от времени Git упаковывает несколько таких объектов в один pack-файл для сохранения места на диске и повышения эффективности.

это больше исключение

Какое же это исключение, если это поведение по умолчанию, а упаковка -- это необязательная оптимизация. Что как бы совсем не

Гит хранит разницу состояний между коммитами – diff.

Как git изменяет содержимое файла?

Полные копии всех состояний не хранятся.

По умолчанию хранятся.

Как в виртуальных процессорах устроена виртуальная память?

любой доступ к памяти, нужно в любом случае, обратится к tlb

SergeySerge11, да.

в любом случае, это вызов функции с передачей параметров, и разбор адреса на n кусков, пара проверок.

Нет, не в любом. В лучшем случае (попадание в собственный TLB QEMU) это извлечение битового поля из виртуального адреса, загрузка значения (кешированный виртуальный адрес) из массива записей TLB по этому индексу и сравнение. Если сравнение успешное -- загрузка ещё одного значения (кешированный физический адрес). На это можно легко посмотреть, если запускать QEMU с ключами -d in_asm, op_opt,out_asm
Например такой вот код

movb    (%rbx), %al
        jmp     1f
1:

генерирует такой вот вывод:

IN:
0x001000ee:  8a 03                    movb     (%rbx), %al
0x001000f0:  eb 00                    jmp      0x1000f2

OP after optimization and liveness analysis:
 ld_i32 tmp11,env,$0xfffffffffffffff0     dead: 1  pref=0xffff
 movi_i32 tmp12,$0x0                      pref=0xffff
 brcond_i32 tmp11,tmp12,lt,$L0            dead: 0 1

 ---- 00000000001000ee 0000000000000000
 qemu_ld_i64 tmp0,rbx,ub,2                dead: 1  pref=0xf
 deposit_i64 rax,rax,tmp0,$0x0,$0x8       sync: 0  dead: 0 1 2  pref=0xffff

 ---- 00000000001000f0 0000000000000000
 goto_tb $0x0
 movi_i64 tmp3,$0x1000f2                  pref=0xffff
 st_i64 tmp3,env,$0x80                    dead: 0 1
 exit_tb $0x7f02d017d480
 set_label $L0
 exit_tb $0x7f02d017d483

OUT: [size=152]
  -- guest addr 0x00000000001000ee + tb prologue
0x7f02d017d540:  8b 5d f0                 movl     -0x10(%rbp), %ebx
0x7f02d017d543:  85 db                    testl    %ebx, %ebx
0x7f02d017d545:  0f 8c 58 00 00 00        jl       0x7f02d017d5a3
0x7f02d017d54b:  48 8b 5d 18              movq     0x18(%rbp), %rbx
0x7f02d017d54f:  48 8b fb                 movq     %rbx, %rdi
0x7f02d017d552:  48 c1 ef 07              shrq     $7, %rdi
0x7f02d017d556:  48 23 7d e0              andq     -0x20(%rbp), %rdi
0x7f02d017d55a:  48 03 7d e8              addq     -0x18(%rbp), %rdi
0x7f02d017d55e:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d561:  48 81 e6 00 f0 ff ff     andq     $0xfffffffffffff000, %rsi
0x7f02d017d568:  48 3b 37                 cmpq     (%rdi), %rsi
0x7f02d017d56b:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d56e:  0f 85 3b 00 00 00        jne      0x7f02d017d5af
0x7f02d017d574:  48 03 77 18              addq     0x18(%rdi), %rsi
0x7f02d017d578:  0f b6 1e                 movzbl   (%rsi), %ebx
0x7f02d017d57b:  48 8b 4d 00              movq     (%rbp), %rcx
0x7f02d017d57f:  88 d9                    movb     %bl, %cl
0x7f02d017d581:  48 89 4d 00              movq     %rcx, (%rbp)
  -- guest addr 0x00000000001000f0
0x7f02d017d585:  66 90                    nop
0x7f02d017d587:  e9 00 00 00 00           jmp      0x7f02d017d58c
0x7f02d017d58c:  48 c7 85 80 00 00 00 f2  movq     $0x1000f2, 0x80(%rbp)
0x7f02d017d594:  00 10 00
0x7f02d017d597:  48 8d 05 e2 fe ff ff     leaq     -0x11e(%rip), %rax
0x7f02d017d59e:  e9 75 2a e8 ff           jmp      0x7f02d0000018
0x7f02d017d5a3:  48 8d 05 d9 fe ff ff     leaq     -0x127(%rip), %rax
0x7f02d017d5aa:  e9 69 2a e8 ff           jmp      0x7f02d0000018
  -- tb slow paths + alignment
0x7f02d017d5af:  48 8b fd                 movq     %rbp, %rdi
0x7f02d017d5b2:  ba 02 00 00 00           movl     $2, %edx
0x7f02d017d5b7:  48 8d 0d bd ff ff ff     leaq     -0x43(%rip), %rcx
0x7f02d017d5be:  ff 15 0c 00 00 00        callq    *0xc(%rip)
0x7f02d017d5c4:  8b d8                    movl     %eax, %ebx
0x7f02d017d5c6:  e9 b0 ff ff ff           jmp      0x7f02d017d57b
0x7f02d017d5cb:  90                       nop
0x7f02d017d5cc:  90                       nop
0x7f02d017d5cd:  90                       nop
0x7f02d017d5ce:  90                       nop
0x7f02d017d5cf:  90                       nop
  data: [size=8]
0x7f02d017d5d0:  .quad  0x000055895af47e50

Если отсюда выкинуть служебный код остаётся следующее:

Загрузка регистра %rbx виртуального процессора в %rbx:
0x7f02d017d54b:  48 8b 5d 18              movq     0x18(%rbp), %rbx

Вычисление адреса записи в TLB QEMU для виртуального адреса в %rbx:
0x7f02d017d54f:  48 8b fb                 movq     %rbx, %rdi
0x7f02d017d552:  48 c1 ef 07              shrq     $7, %rdi
0x7f02d017d556:  48 23 7d e0              andq     -0x20(%rbp), %rdi
0x7f02d017d55a:  48 03 7d e8              addq     -0x18(%rbp), %rdi

Выделение адреса страницы из виртуального адреса в %rbx:
0x7f02d017d55e:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d561:  48 81 e6 00 f0 ff ff     andq     $0xfffffffffffff000, %rsi

Сравнение адреса страницы и виртуального адреса адреса в TLB
0x7f02d017d568:  48 3b 37                 cmpq     (%rdi), %rsi

Если не сходится -- перейти к вызову обработчика эмуляции TLB процессора:
0x7f02d017d56b:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d56e:  0f 85 3b 00 00 00        jne      0x7f02d017d5af

Иначе (сошлось) -- вычислить "физический" адрес по виртуальному:
0x7f02d017d574:  48 03 77 18              addq     0x18(%rdi), %rsi

Загрузить байт из памяти:
0x7f02d017d578:  0f b6 1e                 movzbl   (%rsi), %ebx

Записать загруженный байт в регистр виртуального процессора %al:
0x7f02d017d57b:  48 8b 4d 00              movq     (%rbp), %rcx
0x7f02d017d57f:  88 d9                    movb     %bl, %cl
0x7f02d017d581:  48 89 4d 00              movq     %rcx, (%rbp)

Т.е. 11 команд на преобразование виртуального адреса в "физический" в случае успеха.

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

Нет.

Или вот чтение инструкции из EIP, каждое чтение по адресу, прочесть инструкцию PC+1 будет перед тем как исполнить, на фазе извлечения опять это делать?

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

Как реализован внутри std::tm?

почему выходит вот так:

std::tm tm;
tm.tm_hour+=1600;
std::cout<<tm.tm_mon<<std::endl;//2

Даниил, потому что в этом коде ты не инициализировал переменную tm и печатаешь мусор.

Как быстро округлить timestamp до секунд, минут, часов, дней и т.д.?

unix timestamp

Pavel K, правильнее было бы сказать, что часы нужны в UTC+0.

Как округлить timestamp

Уточни "округлить" заодно: 00:00:01 -> 00:00:00, 00:00:30 -> 00:01:00 ?
2 января -> 1 января, 17 января -> 1 февраля?

Как быстро округлить timestamp до секунд, минут, часов, дней и т.д.?

Если с округлением времени всё относительно легко

часовые пояса/летнее/зимнее время, не, не нужно?

Как в виртуальных процессорах устроена виртуальная память?

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

Vindicar, я помню, что видел упоминания этой техники ещё в конце 90х, но сейчас не могу найти никаких конкретных данных о том, что происходит и на каких процессорах эта техника должна была работать. Процессоры вплоть до i486 вообще не имели архитектурно-видимого кеша, т.е. с их точки зрения кеш был неотличим от основной памяти.
Возможно эта техника была нацелена на внутренний пайплайн процессора, но опять же, пайплайн появился в i486, а уже в pentium pro появилось детектирование самомодифицирующегося кода сбрасывающее пайплайн при обнаружении записи в адреса из которых были прочитаны инструкции в настоящий момент находящиеся в пайплайне.
Короче, это, по всей видимости, очень ограниченный анти-отладочный трюк, работающий только на небольшом подмножестве x86, скорее всего только на i486 и pentium.