OpenBSDの勧め
ふと気になってLenovoで年末年始セールをやってないか、見に行ったのだ。
なんでLenovoかと言うとIBM時代からの付き合いがあるから。国産のF,N,Pとかのやつだと 英語キーボードがチョイス出来なかったので、IBMのやつにしたんだった。 キーボードがごてごてしてるの嫌い。本当は無印良品なHHKがいいのだろうけど、ノーパソって 限定になると、そういう選択も憚られる。日よって、英語キーボードって訳。
昔は国産の某を使ってたけど、わんさかと試供品が付いてきて呆れたものだ。その点IBMは 良心的だったな。以来ずっとこのメーカーですよ。
福袋の期間は、2019/12/27 - 2020/01/05 だけど、続いてニューイヤーセールってのを １月16日までやってる。なんやかんや、何時も安売りの某洋服メーカーみたい。
なんて思ってたら、Windows７のEOLに伴う、買い替え客を視野に入れてるようだ。 ７が終わるまでのカウントダウンが表示されたぞ。ご丁寧なこったい。
所で賞味期限切れになった７は、どういう余生を送らせるんですかね。オイラーの友人は、去年７を棄てて、ぐぐるOSに変更したいって言ってたけど、そろそろですよ。
某雑誌はリナに乗り換え記事が満載だな。Winのあのアプリはリナではこうなってますとか 宣伝に余念が無い。
オイラーなら、壊しても良いパソコンが手に入ったと喜んで、色々なOSを試してみるんだけどな。お勧めは、OpenBSDです。
やや、 Smarter Lenovo Think Devices Inspiring Today’s Workforceこんなのが発表された。無線接続のキーボードですって。独立してるならHHKとコラボしてよね。
enjoy old gosh
前回の最後で、genstubを試供品にして #?= を実行した。どうやらloadなんて手続きが有るじゃん。それを知らなかったオイラーは、repl画面にスクリプトを貼りつけて読み込んでいたぞ。 ちょいと恥ずかしい。ソースを見てないのがバレバレ。
真面目にload.cを見る。
/* C-continuation of the loading */
static void load_cc(ScmObj result, void **data)
{
ScmObj port = SCM_OBJ(data[0]);
ScmObj expr = Scm_Read(port);
if (!SCM_EOFP(expr)) {
Scm_VMPushCC(load_cc, (void **)&port, 1);
Scm_Eval(expr, SCM_UNBOUND);
} else {
Scm_ClosePort(SCM_PORT(port));
SCM_RETURN(result);
}
}
readがEOFを返さない間は、グルグル回りながら評価してくのね。EOFになったら、portを閉じてから、EOFになる直前の結果を返すって事かな。巧妙なやり方だな。
で、CCってのが出てる。VMに何か仕掛けが有るのだろう。vm-dumpなんてのが有ったので、走らせてみる。
debian:tmp$ ./gosh
gosh> (vm-dump)
VM 0x3efc0
argp: ()
pc: (#<source-info (vm-dump)>)
envs:
0x548a0 "[toplevel]"
[ #<module "user"> ]
conts:
dynenv: ()
#<undef>
conts:ってのが、そうかな？ load手続きで使われてるって事は、この手続きを呼べば動き出すのだろうね。
debian:tmp$ cat z.scm (define a 1) (vm-dump)
他愛のないコード
debian:tmp$ ./gosh
gosh> (load "z.scm")
VM 0x3efc0
argp: ()
pc: (#<source-info (vm-dump)>)
envs:
conts:
0x545a0 argp = ()
env = 0x54858
next = (#<c-continuation 0x3ded8> #<source-info (load "z. ...
dynenv: ()
#<undef>
やっぱり使われているね。いかんいかん、つまみ食いは！ 正統にやるなら、ヘッダーファイルを見るのが鉄則。gauche.hが全般的なやつ。VMなマシンなら、vm.hね。180行目ぐらいから、命令表と言うか、説明が載ってた。
at OpenBSD
32Bit機で試していたんだけど、64BitなWindows10からのログインだった。電気の無駄なんで、 Windows10の中のOpenBSDで試してみる。
ob$ ./gosh gosh> (vm-dump) VM 0x78c75747f80 argp: () pc: Segmentation fault (core dumped)
セグフォなんで、検視ですかね。
ob$ gdb -q gosh gosh.core
Reading symbols from gosh...done.
[New process 388774]
Core was generated by `gosh'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000789cf7f2194 in write_internal (obj=0x78c75750240,
out=0x78c75746ec0, mode=0, acclen=0, limit=-1) at write.c:85
85 SCM_PUTC('(', out); nc++;
足取り確認。
(gdb) bt
#0 0x00000789cf7f2194 in write_internal (obj=0x78c75750240,
out=0x78c75746ec0, mode=0, acclen=0, limit=-1) at write.c:85
#1 0x00000789cf7f5dbc in Scm_Vprintf (out=0x78c75746ec0,
fmt=0x789cf7cf00b "#<source-info %S>", ap=0x7f7fffff6d70) at write.c:363
#2 0x00000789cf7f6a26 in Scm_Printf (out=0x78c75746ec0,
fmt=0x789cf7cf00b "#<source-info %S>") at write.c:420
#3 0x00000789cf7e1fde in source_info_print (obj=0x78c757518e0,
port=0x78c75746ec0, mode=0) at compile.c:54
#4 0x00000789cf7f28fe in write_internal (obj=0x78c757518e0,
out=0x78c75746ec0, mode=0, acclen=1, limit=65) at write.c:97
#5 0x00000789cf7f2268 in write_internal (obj=0x78c75750180,
out=0x78c75746ec0, mode=0, acclen=0, limit=65) at write.c:86
#6 0x00000789cf7f2978 in Scm_WriteLimited (obj=0x78c75750180,
port=0x78c75746f40, mode=0, width=65) at write.c:124
#7 0x00000789cf7f5df6 in Scm_Vprintf (out=0x78c75746f40,
fmt=0x789cf7cf237 " pc: %65.1S\n", ap=0x7f7fffff79a0) at write.c:365
#8 0x00000789cf7f6a26 in Scm_Printf (out=0x78c75746f40,
fmt=0x789cf7cf237 " pc: %65.1S\n") at write.c:420
#9 0x00000789cf7e1670 in Scm_VMDump (vm=0x78c75747f80) at vm.c:890
#10 0x00000789cf80d071 in stdlib_vm_dump (SCM_FP=0x78c757500d8, SCM_ARGCNT=1,
data_=0x0) at stdlib.c:3091
#11 0x00000789cf7de61d in run_loop (program=0x78c757501e0) at vm.c:334
#12 0x00000789cf7dd904 in Scm_Run (program=0x78c757501e0) at vm.c:167
#13 0x00000789cf7dc5cb in toplevel () at main.c:28
#14 0x00000789cf7dcea4 in main (argc=1, argv=0x7f7fffff7f48) at main.c:66
64Bit版のOpenBSDだけあって、出て来るポインターの幅が大きいなあ。まあいいや。 追ってみるか。
インタラクティブなアプリをemacs上のgdbからお追うとすると、ちょっとかっかい。リナだと、gdbserver上でアプリを動かして、それをgdb側からコントーロールするのが定番だ。だが、残念ながらOpenBSDにはgdbserverが無いんよ。
こういう場合の定番は、動かしておいたアプリにgdbをアタッチするのが普通。やってみるか。
ob$ ps a | grep gosh 79458 p1 S+p 0:00.01 grep gosh 55309 p2 S+ 0:05.25 ./gosh ob$ gdb -q gosh -p 55309 Reading symbols from gosh...done. Attaching to program: /tmp/small/src/gosh, process 55309 ptrace: Operation not permitted.
うーん、ptraceが拒否された。厳しいTeo親分のガード発動って所だな。なんたって、セキュリティ原理主義（誉め言葉）だからなあ。どうやってかいくぐる。リナでこういう場面に出くわすと、ぐぐるのが定番だけど、、、マニュアルが充実してるOpenBSDなら、
ob$ man ptrace
:
ptrace() is only available on kernels compiled with the PTRACE option.
こういうオプションには突破口が用意されてるのが普通。そしてそれをコントロールしてるのは、sysctlだ。きっとそういう項目が有るに違いない。
ob$ sysctl -a | grep ptrace kern.global_ptrace=0 ob$ doas sysctl kern.global_ptrace=1 doas (sakae@ob.localdomain) password: kern.global_ptrace: 0 -> 1
やっぱり制御フラグが有った。有効にしてあげる。ptrace出来るかな？
ob$ gdb -q gosh -p 55309
Reading symbols from gosh...done.
Attaching to program: /tmp/small/src/gosh, process 55309
Reading symbols from /usr/lib/libm.so.10.1...done.
Reading symbols from /usr/lib/libc.so.95.1...done.
Reading symbols from /usr/libexec/ld.so...done.
[Switching to thread 229216]
_thread_sys_read () at -:3
3 -: No such file or directory.
(gdb) bt
#0 _thread_sys_read () at -:3
#1 0x00000e0818cf1d8e in _libc_read_cancel (fd=0, buf=0xe0825722000,
nbytes=65536) at /usr/src/lib/libc/sys/w_read.c:27
#2 0x00000e0818c71ca2 in __sread (cookie=0xe0818cf72f0 <__sF>,
buf=0xe0825722000 "", n=<optimized out>)
at /usr/src/lib/libc/stdio/stdio.c:48
#3 0x00000e0818cdfb08 in __srefill (fp=0xe0818cf72f0 <__sF>)
at /usr/src/lib/libc/stdio/refill.c:116
#4 0x00000e0818c63f2a in _libc___srget (fp=0xe0818cf72f0 <__sF>)
at /usr/src/lib/libc/stdio/rget.c:46
#5 0x00000e0613bffded in skipws (port=0xe0826b5afc0) at read.c:78
#6 0x00000e0613bfeb05 in read_internal (port=0xe0826b5afc0) at read.c:101
#7 0x00000e0613bfeabf in Scm_Read (port=0xe0826b5afc0) at read.c:42
#8 0x00000e0613be455e in toplevel () at main.c:23
#9 0x00000e0613be4ea4 in main (NAME
ex, vi, view - text editors
argc=1, argv=0x7f7ffffd3d28) at main.c:66
OpenBSDで気に入っているのは、ライブラリィーにも潜って行ける事。これ、とっても為になる場合が有るぞ。リナなんかだと、glibcのdebugバージョンとかを入れなくちゃ実現出来ず、とっても面倒至極ですよ。
ずっとgdbでアタッチして使う積りなら、kern.global_ptrace=1 を、/etc/sysctl.confに書いておくだけでよい。（このファイルは初期状態では存在しない）boot時から有効になる。
install OpenBSD for i386
年末の掃除の時、Windows10のvboxに入れていた少々古めのOpenBSD（32Bit版）を消してしまった。年も改まったので、新しいのを入れてあげるか。
今度は性能がvboxより良いVMWareに入れる事にした。qemeも入れて、カーネルでも触ってみようかと言う魂胆。
約10分でインストール完了。すかさず、rootユーザーで、最初の儀式をやっておく。
doas syspatch cp /etc/examples/doas.conf /etc vi /etc/group operator:*:5:root,sakae ;; add sakae for shutdown -p now vi /etc/fstab swap /tmp mfs rw,nodev,nosuid,-s=1024m 0 0 ;; for ramdisk vi /etc/installurl http://ftp.jaist.ac.jp/pub/OpenBSD ;; define pkg download site vi /etc/ssh/sshd_config X11Forwarding yes ;; enable X11Forwarding shutdown -r now
syspatchでカーネルとか大事なライブラリィーをアップデート。sudoの代わりのdoasの設定を設置。groupを編集してオペレーターの仲間になる。仲間になってると、マシンを停止出来る。 fstabを編集して/tmp領域をRAMDISKに設定。installurlを編集して、近場からパッケージを落とすように設定。おまけで、X11のフォワーディングを許可。そしてreboot。
ごちゃごちゃ書いたけど必須なのはsyspatchだけだ。後はオイラーの趣味。いずれにしろ、ほとんど一行の変更で済んでしまう。分からない事はmanに聞けば、簡潔に答えてくれるしね。
o32$ df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 12378750 1048106 10711708 9% /
X11込み、開発環境込みで、DISKの使用量は、こんなもんだ。
doas pkg_add emacs git curl gdb gmake
後は、使いそうなパッケージを、どんどんと放り込んで行く。
リナとかだと、viと言ってもvimなんだけど、あいつは嫌いだ。ぐだぐだとemacsと張り合わなくて宜しい。viは、由緒あるやつが一番さ。（石投げないでね。個人の好みですから）
NAME
ex, vi, view - text editors
HISTORY
The ex editor first appeared in 1BSD. The nex/nvi replacements for the
ex/vi editor first appeared in 4.4BSD.
AUTHORS
Bill Joy wrote the original version of ex in 1977.
まて、またeditor戦争を始める積り？ まあ、こういう論争なら、トランプ野郎のやりたいやつよりずっと健全ね。
viはいいけどvimは嫌いって事だからね。論点を間違えないでね。どこかのOSはvimをviにしちゃってる。便利ならば全て良しってのが駄目と思ってるのよ。 若し何か有った時、vimがちゃんと動くのだろうか？ 非常時に着飾ったvs code みたいな奴しか無いと困るって事よ。
editorと言うアプリなんだから、何を使おうと勝手。でもそれを、根幹を成すtoolと混同しちゃうってのが気になるのよ。/etc/alternativesに有る切り替え器でviがvim.tinyってなってるよ。
bashもそうだな。shellでTCPを操れるのは便利かも知れない。でもshは根幹を成すやつだからね。bashをshと同一視するOSはどうかと思うよ。debianはshの正体がdashになってた。 そうか、bash語が席巻してると思えばいいのか。
systemdも、わけわかめな設定を持ち込んで、やたら難しい事を強いる。どうなんだかねぇ。墓穴を掘ってるとしか思えんぞ。OpenBSDだと、/etc/rcがユーザーランドの起動の全てだ。明瞭なり！
ってな事で、素直なOSをお勧めします。それがOpenBSD。
emacsとgdbがあれを連れてきた
そう、パッケージから上記を入れると、emacsはpython3.7.4を連れてやってきた。まあ、許してやる。今時pythonぐらい入ってないと馬鹿にされるから。（使わないからどうでもよい）
gdbを入れると、既にEOL（賞味期限切れの事）になった、python2.7.16を引き連れてやってくる。これも使わないからどうでもいいけど、次回は３系にしてね。親分からの警告は無かったのでしょうか？
それには、深ーーい訳が有るのよ。gdbは基本の道具なんで標準で提供されてる。6.3と言う古いやつ。カーネルをdebugするなら、昔から実績のあるこれで十分って訳。
でも、このgdbをemacsから使おうとすると、進み過ぎたemacsの機能に付いていけず、まともに動かないのよ。（オイラーみたいなのが困るのよ）それを解消する為に、有志が新しい版のやつをパッケージとして提供してる。 名前がぶつかるので、パッケージ版の方はegdbってなってる。
こういう事情を斟酌して、お目こぼしにあずかっているに違いない。
emacs and qemu
emacsを入れようとしてpkg_add emacsすると、３種類あるけどどれにするって聞いてくる。細かい事にgtk2版、gtk3版、X無し版。それぞれの事情に合わせて選ぶ事になる。
オイラーは昔からX無し派だったんだけど、それだと特殊キーの扱いが無視されるんで、やむなくgtk2版を入れてる。これだとw3mもgtk2なんで好都合and微妙に容量削減になる。
今回qemuを入れたらgtk3が一緒にやってきた。GUIなアプリなんだね。まあGUIがデフォの人達の作品だからしょうがない。そのうちに今度はQtとか言い出すんだろうか。
tmux
昔はscreenを使っていたけど、OpenBSDでは標準提供って事で、こいつを使っている。
o32$ cat .tmux.conf set -g prefix C-t unbind C-b bind C-t send-prefix set-window-option -g mode-keys emacs set-option -g history-limit 2500 set -g bell-action none bind-key -T prefix Space next-window # PREFIX + : set status off # PREFIX + [ enter copy mode, q to exit copy mode
色々なOSでも使い回ししてるんで、OpenBSDを新たに入れると、よそのOSに初接続した時、必ずこの設定をDLしてますよ。 Ctl-T SPACEで、端末画面の切り替えぐらいしか使ってないけど、一瞬emacsを使ってる気分になって、宜しいですよ。後は2500までさかのぼれる設定かな。
kernel src
qemuでお遊び用のkernelを作る予定なので kernelのソースだけは入れた。 容量は、こんな物
o32$ du -sh sys/
212M sys/
o32$ find sys -name '*.[ch]' | xargs ls | wc -l
6955
o32$ find sys -name '*.[ch]' | xargs wc -l
:
1457 sys/uvm/uvm_vnode.c
94 sys/uvm/uvm_vnode.h
154 sys/uvm/uvmexp.h
1412106 total
非常にシンプル。どこかのOSとは大違い！！
と、OpenBSD信者が吠えております。
portable OpenBSD
小さいシステムなんでUSBに焼いて、持ち運び出来るOpenBSDが簡単に作成出来る。焼くのもddコマンドを叩くだけ。オイラーも非常用に作ってあるぞ。2018年の事だ。
本格的にやるなら、美味しい河豚だ。河豚は福に通じると言うから、正月から目出鯛ぞ。