僕の備忘録(PC、UN*X、ネットワーク関連が中心)なんです。
自分の書いたところは適当(な時とか)に書き換えますので御了承を。
とりあえずは失意体前屈。
サンプルコードを××××して元画像を少しずつずらして複製し、
それを一つの動画に統合。
これで想定通りに動く理由が、実は良くわからなかったり。
gifの動画は、大きい画像の多色表示には向いていないっぽい。
:num1,num2!command ... 覚えたつもりでもすぐ忘れる。
PNG形式の
画像を
HTML形式にする。
スクリーンショットの一部を、gimp で縮小し、画像形式を"HTML"に
指定して保存した。
警告メッセージをみて、より小さくなるよう何度も作りなおす。
$ cat -n screen.html 1 <HTML> 2 <HEAD><TITLE>/path/screen.html</TITLE></HEAD> 3 <BODY> 4 <H1>/home/makoto/screen.html</H1> 5 <TABLE BORDER=2 CELLPADDING=4 CELLSPACING=0> 6 <CAPTION>Made with GIMP Table Magic</CAPTION> 7 <TR> 8 <TD BGCOLOR=#e0dcdf> </TD> 9 <TD BGCOLOR=#d7d3dc> </TD> 10 <TD BGCOLOR=#d4d1da> </TD> 11 <TD BGCOLOR=#dad5da> </TD> 12 <TD BGCOLOR=#838aa2> </TD> 13 <TD BGCOLOR=#8693aa> </TD> 14 (ry 11700 </TR> 11701 </TABLE></BODY></HTML>
ついでに、ghostscriptのサンプル画像でも 少し。
PerlMagickをデスクトップに入れた。
オライリーの本の
サンプルコード(p120)とApache1.3.33の
おまけについてた画像(icons/pie?.gif)で
できた画像がこれ。
ここまでやって○○の90%が消尽した。
なんとなく落として make menuconfig。
昨日の末(30分前)にはできていたが、
/boot/grub.conf の単純な記述ミスが祟って
起動にはしばらくかかった。
SONY PlayStation2のUSBキーボードは、このカーネルでも、 やっぱり扱えない。
特に、逆引きができないと UN*XのLANは遅くなる...のだろうか。
Plamoでproftpdをあげたが、
KNOPPIXからのncftpが遅い。特にログイン後
の"ls"などになかなか反応しない。
今回はtcpdump -q -n しか見てないが、
DNSサーバになにやら問い合わせしている様子は
こないだとよく似ているような気がする。
/etc/resolv.conf
を書き換えても変更が有効にならない。
kill -HUP を喰わせても同様。
proftpdを再起動して、ようやく
(いくらか)スムーズになった。
sendmail(8)は使ってないが...
sendmail(1)はPostfixだし。
root 4452 0.0 0.5 6176 6176 pts/0 DL+ \ 09:42 0:00 cdrecord mmap dev=ATAPI:0,1,0 -tao -eject hoge.iso root 4539 0.0 0.0 0 0 pts/0 Z+ \ 09:42 0:00 [cdrecord.mmap] <defunct> knoppix 5683 0.0 0.0 4832 808 /UNIONFS/dev/ttyS0 S+ \ 10:01 0:00 grep cdrecord
DL+とZ+と<defunct>にぎょっとしたが、すぐCDRWがイジェクトされて、安堵。
Plamo-4.2にcloop.koを追加し、mountしたCDイメージから/KNOPPIX/KNOPPIX をcloopで マウント(# sh KNOPPIX mountpoint)し、中身をファイルシステムに書き出す。 時折I/Oエラーは出てしまう、ことがある。
cpでなくrsyncを使うと便利だ。
I/Oエラーが出たらもう一度やればいい(筈だ)し、簡単に最初に戻せる。
kdebluetoothの削除でコケる原因がkdelock-knoppixパッケージにあるらしいと いう 情報発見。先にこいつを消せば、kdebluetoothもあっさり永眠した。
存在に長く気づかなかったユーティリティ。
なんか悪戯に使えそうな気がする。
えっと、閉めるのは... eject -t。
デフォルトで一般ユーザが使えるのは当たり前なのか、そうでないのか。
場所によっては、Install大会も、また楽しく学べるイベントになり得るに違いない。
Debianはインストール中にproxyを指定しても、再起動後には忘れているらしい。
各アプリケーションにも反映されていないようだ。{{要確認}}
apt-getなどにproxyを通す為には、スーパーユーザの環境変数proxyにホスト及びポートを
指定する。GNOMEのWebブラウザであるEpyphanyはどこでproxyを指定するのか、うまく捜し出せなかった。
Vineのイメージとk3bでCDRを焼き、そのままiMacをリブートさせてVine-PPCをインストールした。
特に考えることもなく進み、再起動後あっさりグラフィカルログインなVineが起動したが、
コンソールでfdisk -l しても何も出なかった。
実はスーパーユーザになっていたかどうか、あまり覚えていない。
Etchのデフォルトデスクトップでも、GUIのツールが色々入っている話。
Win{XP,Vista}しか知らない自称初心者に、とっつきやすものと見えるかどうかはあまり分からなかった。
「DHCPサーバの承認」でしばらく嵌る。
操作(A)から承認(Z)しようとしても「アクセスが拒否されました」。
Adminグループに過ぎないユーザがやっても駄目だったらしい。
「サーバーの役割管理」自体を「別のユーザで実行」するまで、非アドミンで
試行錯誤を続けていた。
やっぱりウィンドウズはアドミニストレーターで操作するものなのかなー
Chapter 5.15のbash-4.0ビルド(がコケる)まで、flex が入ってないことに気づかなかった。
あわてて version-check.sh を実行。そして apt-get 。
chroot を越えてからの進展はかなりのろくなった。
Chapter 6.28 (Libtool-2.2.6a)まで。
Plamo-4.6 を入れ直す。CDで起動し、USB(vfat)に入れたDVDのイメージを
mountして、そちらから。
GNOMEもKDEも一緒くたにする。が、基本的なデスクトップはafterstep。
閏年かどうかの判定に、例外処理を入れてみた。
#!/usr/bin/env python3 import sys def leap(x): if(x % 4 == 0 and x % 100 != 0) or ( x % 400 == 0): print("{} is a leap year".format(x)) else: print("{} is not a leap year".format(x)) try: x = int(sys.argv[1]) leap(x) except: print("There is no parameter or wrong ones.")
$ ./leap.py ahoka There is no parameter or wrong ones. $ ./leap.py There is no parameter or wrong ones. $ ./leap.py 1900 1900 is not a leap year $ ./leap.py 2000 2000 is a leap year $ ./leap.py 2010 2010 is not a leap year
ツッコミを受けて追試。今回の $HOST_A' は、手元のPPPoEな ルータの後ろにあるFreeBSD 8.1-RELEASE。
$HOST_A':$ traceroute -an $HOST_B traceroute to $HOST_B ($HOST_B), 64 hops max, 40 byte packets 1 [AS8151] $BROUTER 0.412 ms 0.380 ms 0.296 ms 2 [AS2497] 210.130.139.104 12.855 ms 12.833 ms 13.248 ms 3 [AS2497] 210.130.139.97 13.780 ms 14.110 ms 14.456 ms 4 [AS2497] 210.130.143.37 13.519 ms 14.079 ms 13.982 ms 5 [AS2497] 58.138.106.153 13.279 ms 13.872 ms 14.477 ms 6 [AS2497] 58.138.106.42 14.018 ms 13.861 ms 13.229 ms 7 [AS2497] 210.130.146.186 24.126 ms 23.473 ms 23.362 ms 8 [AS9609] 218.185.186.38 23.097 ms 23.526 ms 22.906 ms 9 [AS37903] 117.55.2.22 24.293 ms 23.703 ms 24.337 ms 10 [AS37903] $HOST_B 341.154 ms 325.902 ms 267.499 ms
linux にあった Traceroute for Linux も -A が有効だった。
$HOST_B:$ traceroute -nA $HOST_A traceroute to $HOST_A ($HOST_A), 30 hops max, 60 byte packets 1 117.55.2.6 [AS37903] 702.542 ms 704.517 ms 704.490 ms 2 117.55.2.17 [AS37903] 704.465 ms 704.440 ms 704.417 ms 3 218.185.186.33 [AS9609] 705.369 ms 705.350 ms 705.332 ms 4 211.14.193.9 [AS9609] 705.315 ms 86.849 ms 106.785 ms 5 210.130.134.65 [AS2497] 107.751 ms 108.727 ms 126.696 ms 6 58.138.82.25 [AS2497] 136.643 ms 58.138.82.29 [AS2497] \ 156.619 ms 58.138.82.41 [AS2497] 107.920 ms 7 58.138.81.178 [AS2497] 108.847 ms 58.138.81.210 [AS2497] \ 128.817 ms 58.138.81.90 [AS2497] 129.792 ms 8 58.138.81.102 [AS2497] 130.767 ms 58.138.81.106 [AS2497] \ 149.745 ms 58.138.81.142 [AS2497] 148.729 ms 9 58.138.106.158 [AS2497] 150.705 ms 58.138.106.154 [AS2497] \ 157.689 ms 176.884 ms 10 210.130.143.38 [AS2497] 206.834 ms 246.798 ms 286.761 ms 11 210.130.139.104 [AS2497] 326.728 ms 346.703 ms 406.675 ms 12 $HOST_A [AS2497] 198.859 ms 218.814 ms 258.779 ms
流石にこのあたりとなると、7年前の実習なんてほとんど忘れている。
ping -c 1 やってみた。
10回くらいのところで、linux kernel を wget して、
終わって10回くらい待っている。
パケットロスは発生しなかった。
表示はスプライン。
jessieじゃなくてtrustyなんだけど、まあいいか。
ほとんど小さくならない。もともと圧縮しているはず。
$ du -ch *.png | tail -n1 31M 合計 $ tar cfz png.tar.gz *.png $ tar cfj png.tar.bz2 *.png $ tar cfJ png.tar.xz *.png $ ls -alFh *.tar.* -rw-rw-r-- 1 user group 30M 6月 16 19:03 png.tar.bz2 -rw-rw-r-- 1 user group 30M 6月 16 19:05 png.tar.gz -rw-rw-r-- 1 user group 29M 6月 16 19:06 png.tar.xz
2^128-1と+1で計算時間が大違いだった。
FreeBSD 11.0-RELEASE-p9 のfactorでは
後者の計算ができないみたい(非常に長く待たされただけ)。
で、すべてDebian + GNU coreutils-8.27(GMPリンク)。
まずはx86_64(i3-4130)のstretch。
coreutils-8.27$ time echo 2^128-1 | bc | ./src/factor 340282366920938463463374607431768211455: 3 5 17 257 641 \ 65537 274177 6700417 67280421310721 real 0m0.009s user 0m0.004s sys 0m0.004s coreutils-8.27$ time echo 2^128+1 | bc | ./src/factor 340282366920938463463374607431768211457: 59649589127497217 \ 5704689200685129054721 real 2m1.007s user 2m1.004s sys 0m0.000s
以後はtimeの結果のみとする。
RaspberryPi B。
real 0m0.113s user 0m0.080s sys 0m0.010s real 67m59.937s user 67m10.890s sys 0m2.270s
i686のjessie(Pentium M 1.6GHz)。
real 0m0.416s user 0m0.024s sys 0m0.000s real 14m31.257s user 14m25.684s sys 0m0.064s
RaspberryPi 3
real 0m0.055s user 0m0.030s sys 0m0.000s real 23m5.198s user 23m5.130s sys 0m0.010s
それに733MHzのPowerPC搭載のPowerMac G4(jessie)。
real 0m0.174s user 0m0.032s sys 0m0.012s real 33m44.304s user 33m35.720s sys 0m0.264s
160GBのHDDから、1TBにddrescueしてみる。
やり方はこないだと同じ。focalのUSBメモリで起動し、
gddrescueなどをapt-getし、リモートログインして操作。
$ time sudo ddrescue -f /dev/sda /dev/sdb ddb GNU ddrescue 1.23 Press Ctrl-C to interrupt ipos: 86372 MB, non-trimmed: 0 B, current rate: 52559 kB/s ipos: 160041 MB, non-trimmed: 0 B, current rate: 19030 kB/s opos: 160041 MB, non-scraped: 0 B, average rate: 49198 kB/s non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s rescued: 160041 MB, bad areas: 0, run time: 54m 12s pct rescued: 100.00%, read errors: 0, remaining time: n/a time since last successful read: n/a Finished real 54m13.300s user 0m16.712s
実は前に一度試していたが、dmesgに山ほどエラーが出ていた。
今日は全くその手のメッセージが出ず、極めて安定的に進行、終了。
でも起動できなかった。
仕掛けておいたiostatやsarが興味深かった。
徐々に読み込み速度が低下する様子(ディスクの周辺部から中央部付近
に近づいている)とか、書き込みはほとんど違わない(大きいから
あまり中央に近づく前に終わる)とか、たぶん
読み込み速度いっぱい
らしいこととか、
4つのCPUをうまく振り分けてるかどうか
あまり分からないこととか。
500GBのHDDを1TBにddrescueしたが、こちらは 起動できるものができた。
$ time sudo ddrescue -f /dev/sda /dev/sdb GNU ddrescue 1.23 Press Ctrl-C to interrupt ipos: 500107 MB, non-trimmed: 0 B, current rate: 9265 kB/s opos: 500107 MB, non-scraped: 0 B, average rate: 87187 kB/s non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s rescued: 500107 MB, bad areas: 0, run time: 1h 35m 35s pct rescued: 100.00%, read errors: 0, remaining time: n/a time since last successful read: n/a Finished real 95m35.287s user 0m44.399s sys 14m33.520s
続きは、また思い出した時にでも。
で、インストールメディアに書き込んでみた。
USBメモリが手元になく、MicroSDをUSBに挿す
インターフェースがあったので、それを使うことにする。
例によってttyrecとscriptで表示を書き出し、 別ウィンドウでiostat -y -x 1 | tee iostat。
$ time sudo ddrescue -f debian-11.3.0-amd64-netinst.iso /dev/sdb log GNU ddrescue 1.26 Press Ctrl-C to interrupt ipos: 396296 kB, non-trimmed: 0 B, current rate: 6619 kB/s opos: 396296 kB, non-scraped: 0 B, average rate: 23315 kB/s non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s rescued: 396361 kB, bad areas: 0, run time: 16s pct rescued: 100.00%, read errors: 0, remaining time: n/a time since last successful read: n/a Copying non-tried blocks... Pass 1 (forwards) Finished real 0m30.054s user 0m0.004s sys 0m0.012s
rateのグラフ、時間が半分、いや2/3くらいになっている。まだ改善の余地がありそう。
リンクはご自由にどうぞ。でもURLや内容が変った場合はあしからず。