ショウジョウバエ(Drosophila)は複眼の網膜を動かすことで、体や頭を動かさずに見るところを変えられるらしい。
Fenk, L.M., Avritzer, S.C., Weisman, J.L. et al. Muscles that move the retina augment compound eye vision in Drosophila. Nature 612, 116–122 (2022).
[PV1]─→[VG1]┬→[LV-root]
└→[LV-swap]
であるとき、これを
[PV1]┬→[VG1]┬→[LV-root] [PV2]┘ └→[LV-swap]のように変更し、増えた容量をLV-rootに割り当てます。 PV2が新しく追加したディスクをLVMのPhysical volumeにしたものになります。
$ cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdc実行するとパスフレーズの入力を要求されるので、設定したいパスフレーズを入力します。 なお、暗号化アルゴリズムとキーサイズの設定は参考文献のままですので、必要に応じて変更します。 さきほど設定したパスフレーズが正しく入力できたか確認するために、次のコマンドを実行します。
$ cryptsetup luksOpen /dev/sdc sdc_crypt成功したら次のステップに進みます。
cryptsetup luksDump /dev/sdcを実行すると、暗号化ディスクの情報が表示されます。
UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxのxxx部分がUUIDですので、この値を$(UUID)と書くことにします。 UUIDがわかったので、/etc/crypttabに次の一行を追加します。
sdc_crypt UUID=$(UUID) none luks,discard,initramfs行の最後にinitramfsと書いておくのがポイントです。 編集を終えたら、
$ update-initramfs -uを実行して、OSの起動時の処理内容を更新します。 これにより、追加したディスクのパスフレーズによる暗号化の解除処理をOSの起動時に実施できるようになります。 リブートして、起動時に暗号化を解除できるか確認します。 リブートすると、これまで通り、Debianインストール時に暗号化したディスクに対するパスフレーズの入力を求められ、 続いて、今回追加したディスクのパスフレーズの入力を求められます。 もし、パスフレーズの入力回数が増えていない（＝今回追加したディスクのパスフレーズの入力が求められない）状態の場合、 なにか失敗しているので、これ以降のLVMの変更手順は実行してはいけません。OSが起動しなくなります。 今回追加したディスクのパスフレーズの入力を求められ、暗号化を解除したうえでOSが起動すると、 /dev/mapperにsdc_cryptが加わっているはずです。
pvcreate /dev/mapper/sdc_crypt追加したPhysical volumeを既存のVolume group (ここではxxx-vg)に追加します。
$ vgextend xxx-vg /dev/mapper/sdc_crypt追加できたか確認します。
$ vgdisplay -vの最後のほうに、Volume groupを構成するPhysical volumeが表示されますので、それで確認ができます。 さらに、Total PE / Free PEの行を見ると、Free PEの値がわかるので、この値を覚えておきます。 ここではこの値を$(Free)とします。 Logical volumeのうち、rootのvolumeの容量を増やします。
$ lvextend -l +$(Free) /dev/xxx-vg/rootもし、$(Free)が1000なら
$ lvextend -l +1000 /dev/xxx-vg/rootとします。 最後に、ファイルシステムの容量を増やします。ext2またはext3、ext4であれば、
$ resize2fs /dev/xxx-vg/rootを実行することで、ルートのディスク容量が追加したディスクの容量分だけ増えます。 他のファイルシステムを使っている場合は、適切なコマンドを実行して容量を増やします。 これで容量が増えているはずなので、dfなどでディスク容量が増えていることを確認します。 容量が予定通り増えていれば、最後にリブートして、OSが問題なく起動するか確認します。 正常に起動すれば、作業は完了です。
TERM=xterm-256colorとなっていました。
TERM=screen-256colorを設定するだけです。この方法の欠点は、一部がイタリック体になってしまうことです。 また、lessにも影響があり、文字列検索時の強調表示がイタリック体になってしまいます。
$ mkdir -p ~/.terminfo/s/ $ cp /usr/lib/terminfo/x/xterm-256color ~/.terminfo/s/screen-256colorそして
TERM=screen-256colorを設定します。こうすると、設定内容はxterm-256colorのままで、名前だけscreen-256colorに変更したものが参照されるようになります。 emacsがTERMの名前でカラーテーマを決めているようで、端末の全体的な設定はもとのまま、emacsの色だけTERM=screen-256colorと同じにできます。
M-x customize-variable [ENTER] frame-background-mode [ENTER]を実行します。次のような画面が表示されるので、
For help using this buffer, see [Easy Customization] in the [Emacs manual].
[ Search ]
Operate on all settings in this buffer:
[ Revert... ] [ Apply ] [ Apply and Save ]
Hide Frame Background Mode: [Value Menu] automatic
[ State ]: SAVED and set.
The brightness of the background. Hide
Set this to the symbol ‘dark’ if your background color is dark,
‘light’ if your background is light, or nil (automatic by default)
if you want Emacs to examine the brightness for you.
If you change this without using customize, you should use
‘frame-set-background-mode’ to update existing frames;
e.g. (mapc 'frame-set-background-mode (frame-list)).
Groups: [Faces]
[Value Menu]のところにカーソル(キャレット?)を合わせて、[ENTER]を押すと、
Available choices: 0 = dark 1 = light 2 = automaticのように選択肢が表示されます。今回は背景が黒であるという前提ですので、0を押します。 その後、[ Apply and Save ] にカーソルを合わせて[ENTER]を押せば、設定が保存されます。
$ infocmp xterm-256color|egrep "sitm|ritm" rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,のようにsitmとritmに設定されているにも関わらず、対応するところでは文字の色が反転してしまいます。一方、screen-256colorでは
$ infocmp screen-256color|egrep "sitm|ritm"のように項目が設定されていません。このscreen-256colorをTERMに使うとなぜかイタリック体になってしまいます。 さらに、https://gist.github.com/riobard/9166725を参考に、次の内容をscreen-256color-noitalic.terminfoとして保存し(ファイル名は任意)、
screen-256color-noitalic|screen with 256 colors with no italic, sitm=\E[7m, ritm=\E[27m, use=screen-256color,次のコマンド
$ tic screen-256color-noitalic.terminfoを実行すると、
~/.terminfo/s/screen-256color-noitalicというファイルができ、TERMに設定できるようになるので、
TERM=screen-256color-noitalic emacs nanika-fileで実行してみても、上部に表示されるemacsのメニューの文字列がイタリック体のまま変化しません。lessでも同じです。
$ infocmp screen-256color screen-256color-noitalic
comparing screen-256color to screen-256color-noitalic.
comparing booleans.
comparing numbers.
comparing strings.
ritm: NULL, '\E[27m'.
sitm: NULL, '\E[7m'.
のように差があるにも関わらずです。不思議ですね。どこかで何か設定があり、優先されているのでしょう。
なお、\E[3mがイタリックの開始、\E[23mがイタリックの終了、\E[7mが色反転の開始、\E[27mが色反転の終了です。
例えば、
echo -e "\E[3mitalic\E[23m \E[7mrev\E[27m"を端末で実行すると、イタリック体や色反転で表示されることが確認できます。
いまさらではあるものの、Self-attention (自己注意)の計算方法について途中の行列の形状に着目して調べてみました。
結果だけ知りたい方は、最後のまとめに進んでください。
def compute_qkv(query_antecedent, ←これがcommon_kayers.layer_preprocess(x, hparams)
memory_antecedent, ←これがNone
total_key_depth,
total_value_depth,
...
となっていて、memory_antecedentがNoneであることは、呼び出し元のtransformer_encoder:213に戻るとわかります。
memory_antecedentがNoneならquery_antecedentにしているので、self-attentionの場合、入力はquery_antecedentと考えればよさそうです。
さて、Q, K, V (コード中ではq, k, v)はcompute_attention_componentで計算されていて、入力は
antecedent: a Tensor with shape [batch, length, channels]戻り値が
c : [batch, length, depth] tensorとなっています。filter_widthによって処理内容が異なるようですが、filter_width == 1のケースを見てみると、 4415行目で
return common_layers.dense(
antecedent, total_depth, use_bias=False, name=name,
layer_collection=layer_collection)
のように書かれています。バイアスなしなので、単にMatMulの計算をしているだけになります。
Tensorflowのドキュメントによると、
Dense implements the operation: output = activation(dot(input, kernel) + bias) <中略> kernel is a weights matrix created by the layer,なので、
q = (batch, length_q, total_key_depth) k = (batch, length_kv, total_key_depth) v = (batch, length_kv, total_value_depth)となっていることがわかります。
Args:
q: Tensor with shape [..., length_q, depth_k].
k: Tensor with shape [..., length_kv, depth_k]. Leading dimensions must
match with q.
v: Tensor with shape [..., length_kv, depth_v] Leading dimensions must
match with q.
と書かれています。
まず、1648行目で、
と計算しています。論文中の式(1)の\(QK^T\)の部分です。logits = tf.matmul(q, k, transpose_b=True)
で計算されています。weightsの形状はlogitsと同じです。 ドロップアウトの処理をした後、1667行目のweights = tf.nn.softmax(logits, name="attention_weights")
で、式(1)の計算が完了します。これは、return tf.matmul(weights, v)
Returns:
Tensor with shape [..., length_q, depth_v].
と書いてあります。
以上の計算の途中で得られる[weights]の形状が(..., length_q, length_kv)となっており、
self-attentionの場合はlength_q=length_kvですので、系列長の2乗で必要になるメモリや計算量が増えていくことになります。
Intel CPUの64bit環境下で、Dockerを利用してRaspberry Piの32bit OS環境を動かしてみます。
$ docker image import ./root.tar.xz pi11-32bit:2022-04-07とします。インポートできたかは、
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE pi11-32bit 2022-04-07 d2b599f3a584 23 seconds ago 1.16GBのようにして確認できます。 この時点では、まだ実行できません。
$ docker run -it pi11-32bit:2022-04-07 bash exec /usr/bin/bash: exec format error（以下、方法2を実施し、その後、リブートした後に方法1を実行しましたが、もしかすると方法2の影響が残っている可能性があります)
$ docker run -it --rm pi11-32bit:2022-04-07 uname -m armv7lのようにエラーが起きずに実行できるようになります。
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yesを実行します。イメージがダウンロードされて、その後、実行されます。 実行が完了すると、ホストPC側に/proc/sys/fs/binfmt_misc/qemu-*が作成され、
$ docker run -it pi11-32bit:2022-04-07 bash -c ls bin boot dev etc home lib lost+found media mnt opt proc root run sbin srv sys tmp usr varのように動くようになります。 なお、ホストPCをリブートすると、ホストPCで
$ ls /proc/sys/fs/binfmt_misc/ python3.9 register statusとなり、qemu-で始まるファイルがなくなります。また、
$ docker run -it pi11-32bit:2022-04-07 bash exec /usr/bin/bash: exec format errorとなり、実行できない状態になります。
mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_miscと書かれており、カーネルモジュール binfmt_misc をマウントしています(lsmodを実行するとbinfmt_miscが存在することが確認できます)。 少なくともここでホストのルート権限が必要になり、--previlegedをつけることになります。 また、register.shの最後に呼び出されているファイルはおそらく https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh で、この中のqemu_register_interpreter()にて
qemu_generate_register > /proc/sys/fs/binfmt_misc/registerという記述があることから、最終的にbinfmt_miscに対して自動的にqemuを動作させるよう登録をしています。
gir は GObjectIntrospection Repository の略とのこと。
DebianやUbuntuのパッケージの中に先頭に gir1.2- が付くパッケージが多数あり、このgirとは何だろうということで調べてみたところ、Windows10環境でFirefox 97にアップデートしてペンでタブを移動させられなくなってしまった場合は、about:configから
dom.w3c_pointer_events.dispatch_by_pointer_messagesをfalseに設定しましょう。これで、ペンでタブを移動させられるようになります。 タッチ操作でできる画面のスクロールがペンではできなくなりますが、マウスと同様にテキストを選択できるようになるので、マウスの代わりに利用したい方にはこちらのほうが都合が良いでしょう(そもそも以前はこちらがデフォルトの動作でした)。
省電力モードが「エコ」モードを選択した場合、WAN 側回線「5G」は無効となります。と記載がありました（最初の「が」は「で」の誤植っぽいですが、原文ママです）。 というわけですので、通信が切れて困っている方、X11であれば「エコ」モードにすればもしかしたら問題がましになるかもしれません。