Вот если рассмотреть файл побитно до сжатия без потерь и после сжатия (результат), можно заметить интересную картину: в результирующем файле (по сравнению с исходным, особенно, если сжать удалось в несколько раз) мы можем увидеть гораздо более длинные цепочки подряд идущиех битыов, равных 1, аналогично и для равных 0.
Существует какое-то объяснение этого явления?
А я понимал это так, что это об аксиомах… т.е. для построения теории нужны аксиомы, утверждения, доказательство которых в рамках этой теории не рассматривается, невозможно и т.д.
бит, bit (с приставками кило, мега, гига, тера и т.п.) — объем информации (двоичной).
бит/с, bps, bits per second — пропускная способность, скорость передачи, это мощность канала передачи, аналог кВт.
BDP (bandwidth delay product) = бит/с * RTT (round trip time, круговая задержка в секундах) — объем информации, проходящей через канал связи, «находящейся в нём» до момента, пока от получателя не придёт подтверждение, аналог кВт*ч.
Тогда (бит/с)/с — скорость изменения, например, возрастания пропускной способности канала связи, аналог Вашей скорости строительства электростанций.
В Вашем руководстве для sssd на втором сервере используется отдельный keytab, причём для принципала, соответствующего контроллеру. А не проще и правильнее сначала сделать net ads join, образуется /etc/krb5.keytab (если не образуется, то вызвать net ads keytab create) с принципалом второго сервера, который и использовать в sssd, с указанием этого второго принципала?
т.е.
Это упрощенный пример, он не делался с целью дать готовое приложение. Если что-то очень плохо сделано, например, «учит плохому», Вы скажите об этом явно, т.е. что надо переделать.
Это упрощенный пример, он не делался с целью дать готовое приложение. Если что-то очень плохо сделано, например, «учит плохому», Вы скажите об этом явно, т.е. что надо переделать.
подскажите, пожалуйста, а в iSCSI варианте MSA 2040 эта проблема как была, так и осталась?
https://lists.centos.org/pipermail/centos/2013-October/137474.html HP,P2000G3 FC/iSCSI We're having a problem where syslog on every server connected to the SAN is getting spammed with the following:
kernel: sd X:0:0:Y [sdX] Warning! Received an indication that the LUN assignments on this target have changed. The Linux SCSI layer does not automatically remap LUN assignments.
None of the LUN assignments of any of the volumes on the SAN have changed since mapping them to the ports connected to each individual server.
Ясно. И вот еще, я рассматриваю биты архивного файла. Вижу, что чередующиеся наборы одинаковых битов удлиняются по сравнению с неким произвольным исходным файлом. Может ли быть объяснение этому явлению? Наблюдается для разных архиваторов и разных алгоритмов.
Про специализированный/универсальный архиватор — да. Под «случайным» файлом Вы имели в виду, наверное, то, что архиватор на выходе выдает файл с псевдослучайной последовательностью? Я не сразу понял. И распределение там биномиальное, p~0,5? М.б. это в виде теоремы оформлено? Если знаете, подскажите, пожалуйста.
Иными словами, не любую случайную последовательность можно сжать. С этим я согласен, а вот то, что в случайном файле 0 и 1 примерно поровну, это вряд ли.
Ну я не пытался утверждать, что это истина. Это всего лишь наблюдение, анализировал биты сжатых файлов. Более того, в сжатых файлах цепочки одинаковых битов становятся длинными. Так почему?
Про слепого капитана напомнило Платон, Государство, 488, b
Существует какое-то объяснение этого явления?
бит, bit (с приставками кило, мега, гига, тера и т.п.) — объем информации (двоичной).
бит/с, bps, bits per second — пропускная способность, скорость передачи, это мощность канала передачи, аналог кВт.
BDP (bandwidth delay product) = бит/с * RTT (round trip time, круговая задержка в секундах) — объем информации, проходящей через канал связи, «находящейся в нём» до момента, пока от получателя не придёт подтверждение, аналог кВт*ч.
Тогда (бит/с)/с — скорость изменения, например, возрастания пропускной способности канала связи, аналог Вашей скорости строительства электростанций.
т.е.
ldap_krb5_keytab = /etc/krb5.keytab
ldap_sasl_authid = samba3@SAMBA4.SERVDESK.RU
имя определить через klist -k /etc/krb5.keytab.т.к. буквы в имени м.б. и заглавными
https://lists.centos.org/pipermail/centos/2013-October/137474.html HP,P2000G3 FC/iSCSI We're having a problem where syslog on every server connected to the SAN is getting spammed with the following:
kernel: sd X:0:0:Y [sdX] Warning! Received an indication that the LUN assignments on this target have changed. The Linux SCSI layer does not automatically remap LUN assignments.
None of the LUN assignments of any of the volumes on the SAN have changed since mapping them to the ports connected to each individual server.
размер файла 785816*8=6286528 битов
длина набора одинаковых битов 0, частота
s=2830297
4 55423 т.е. последовательность битов 0000 встречается 55423 раза
3 209814
2 497036
1 985091
длина набора одинаковых битов 1, частота
s=3456231
8 5327 т.е. последовательность битов 11111111 встречается 5327 раз
7 8680
6 23785
5 53878
4 161519
3 139320
2 521863
1 832993
исходный файл, сжатый bz2, размер 390916*8=3127328 битов
сжатый файл, длина набора одинаковых битов 0, частота
s=1555468
26 2
17 1
16 6
15 11
14 29
13 84
12 180
11 405
10 854
9 1707
8 3125
7 5996
6 11862
5 23550
4 47024
3 94969
2 194755
1 404715
сжатый файл, длина набора одинаковых битов 1, частота
s=1571860
935 1 т.е. 1 раз в файле встречается 935 подряд идущих битов = 1
88 1
84 1
71 1
67 2
62 1
61 1
59 1
57 1
51 1
49 1
45 1
44 1
43 6
42 3
41 2
38 2
37 1
35 1
34 1
33 1
30 1
29 2
27 1
26 2
25 5
24 4
23 2
22 5
21 2
20 9
19 14
18 14
17 22
16 26
15 35
14 72
13 89
12 201
11 380
10 582
9 1444
8 2555
7 5339
6 11821
5 24595
4 50123
3 100066
2 195029
1 396805
Или вот пример создания файлов, которые жмутся на примерно 50%
crfile.sh
---------------------------
test -f ucfile && rm ucfile
touch ucfile
for ((j=1;j<=10000;j++))
do
s=""
for ((i=1;i<=4;i++))
do
x=$((($RANDOM+1)/16384))
test $x -eq 0 && s=«01$s»
test $x -eq 1 && s=«10$s»
done
n=$(echo «obase=10; ibase=2; $s»|bc)
printf "\\$(printf '%03o' "$n")">>ucfile
done
stat -c "%s %n" ucfile
gzip ucfile
stat -c "%s %n" ucfile.gz
gunzip ucfile.gz
7z a ucfile.7z ucfile 2>&1 >/dev/null
stat -c "%s %n" ucfile.7z
rm ucfile.7z
bzip2 ucfile
stat -c "%s %n" ucfile.bz2
bunzip2 ucfile.bz2
---------------------------
sh ./crfile.sh
10000 ucfile
5814 ucfile.gz
5785 ucfile.7z
5185 ucfile.bz2