バジルの種類。

技術とは全然関係ありませんが、どこかにメモしておかないと忘れてしまうので。

バジルについてです。


通称 現地名 英語 学名 メモ
ホーリーバジル ガパオ
トゥルシー
Holy Basil Ocimum tenuiflorum ハーブ茶、炒めもの、
アロマオイルなど
タイバジル
タイスイートバジル
ホーラパー Thai Basil
Horapha
Asian Sweet Basil
Ocimum basilicum ゲンキョワーンとか
シャムクイーンバジル Siam Queen Basil Ocimum basilicum
台湾バジル 九層塔 Taiwanese Basil Ocimum citriodorum
レモンバジル Lemon Basil Ocimum citriodorum サラダとか収穫後、オリーブオイルを
絡めて冷凍保存
マンモスバジル
スイートマンモスバジル
Mammoth Basil
Sweet Mammoth Basil
Ocimum basilicum 松の実、オリーブオイル、にんにく、
チーズとあわせてバジルソースに
ジェノベーゼバジル
スイートバジル
Genovese Basil
Sweet Basil
バジルペーストとか炒めもの
パープルラッフルバジル Purple Ruffles Basil Ocimum basilicum カリフォルニアの赤紫蘇?
酢に漬けると赤くなる
シナモンバジル Cinnamon Basil Ocimum basilicum カリフォルニアの青じそ?
ハーブビネガーなど

vimtexがfiletypeで起動しない。その2

Neovim で\(\rm\TeX\)ファイルを編集するときに vimtex が正常に動作していなかった件ですが、どうやら原因がわかりました。

Neovim で編集する\(\rm\TeX\)ファイルを読み込むときにパス名に日本語が含まれていると、vimtex が以下のようなエラーを出します。

Error detected while processing function vimtex#init[4]..50_init_state[1]..vimtex#state#init[1]..52_get_main[24]..52_file_is_main:
line   10:
E484: Can't open file C:\Users\kats\Google_Drive\サーバードキュメント\Setting_up_Manjaro_Linux.tex

Neovim 自体ではこのファイルは正常に開けますが、vimtex が読み込むときにエラーを起こしているようです。具体的にどの文字が悪さしているのかは「ダメ文字」で検索してみると、どうやら「ー」が該当するようです。

これを回避するための方法は2つあります。

  1. ダメ文字を使わないこと。一番確実なのは日本語を使わないことでしょう。
  2. 「ベータ: ワールドワイド言語サポートでUnicode UTF-8を使用(U)」を使ってシステムのエンコーディングを UTF-8 にすること。

他にも vimtex 側で対処してもらうとかありそうですが、UTF-8 にすればダメ文字の呪いから開放されるので、その場合にはファイル名やパス名に日本語が容赦なく使用できます。

defaultuser100000。

Windows 10 May 2019 update (1903)をしたノートPCで、ふと c:\Users を見ると、defaultuser100000 というユーザができていました。これまで通り Default というユーザは別にあります。

調べてみると、Windows 10 Update created a default user accountになにやら書いてあります。

ユーザアカウントをリネームしたときにバックアップを消すことができなかったとかそんな感じです。

そのまま削除しても問題はないようですが、ユーザアカウントがダブっていないか確認したほうがいいようなことが書いてあります。

  1. まず、netplwizで自分が使用しているユーザアカウント名を確認します。また同時に他のユーザアカウントがログオンしていないかどうかも確認します。
  2. 管理者モードでコマンドプロンプトを開いて、whoami /user を実行して SID を確認します。
  3. regedit を起動して、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList からユーザリストに先程の SID があるかどうかを確認します。それが自分の SID であれば問題ありません。ProfileImagePath を確認して、ユーザプロファイルディレクトリがちゃんと設定されていること、また StateValue data0 であることを確認して、問題なければ特にすることはありません。
  4. もし同じSIDのキーが2つあった場合には以下のようにします。
    1. SID に ".bak" がついていた場合には、リネームして末尾の ".bak" を削除します。
    2. ProfileImagePath を開いて、ユーザプロファイルディレクトリが正しいことを確認し、また StateValue data0 であることを確認して、問題なければ終了します。
  5. もし ".bak" なしとありの同じSIDのキーが合った場合には以下のようにします。
    1. ".bak" がないほうの SID キーを削除します。
    2. ".bak" があるほうの SID キーをリネームして、末尾の ".bak" を削除します。
    3. あとは上と同じです。

だそうです。
うちの場合には、上記とは異なり、"cyg_server" という別のユーザアカウントがあることを見つけたのでそれも一緒に削除しました。

LaTeXでのダッシュ。

\(\rm\LaTeX\)でのダッシュで、vimtexではチェックに使っているchktexが"Wrong length of dash may have been used. (8)"という警告を出してきます。

w0rp/aleでこれを抑制するには、

let g:ale_tex_chktex_options = "-n 8"

などとすれば8のチェックを無視してくれるようになるのですが、そもそもこのダッシュの使い方をきちんと理解していないのでまとめです。

ダッシュ類の使い方は言語によって異なるので、ここではあくまで英語を取り上げます。

When should I use an em-dash, an en-dash, and a hyphen?に詳細が説明されていますが、

  • "-" : ハイフン。2つ以上の単語の間をつなぐのに使う。
  • "--" : en-dash。範囲を示すのに使う。"3--7"など。
  • "---" : em-dash。文中のカッコと同様の使い方---たとえばこんな風に---をする。

だそうです。

vimtexがfiletypeで起動しない。

Neovim-Qtとlervag/vimtexで\(\rm\LaTeX\)文書をドラッグ&ドロップするとちゃんと動いていたのに、起動しなくなってしまいました。

検索してみたところ、vimtexのhelpになにか書いてありました。

COMMENT ON INTERNAL TEX PLUGIN                        *vimtex-comment-internal*

Vim ships with some LaTeX support out of the box. In particular, it provides
good syntax highlighting (|ft-tex-syntax|), indentation (see the source file
$VIMRUNTIME/indent/tex.vim for the documentation), and some sensible options
(|ft-tex-plugin|).

When |vimtex| is active, it will be used as the main |ftplugin|. It will
define the same set of sensible settings as the internal plugin. However,
|vimtex| does not provide its own syntax, instead it adds a few minor
improvements to |ft-tex-syntax|, see |vimtex-syntax|. |vimtex| also provides its
own indentation plugin, see |vimtex-indent|.

Vim will generally autodetect filetypes automatically. In most cases this
works as expected, however, in some cases it will detect a file with the `tex`
suffix as a |plaintex|. To prevent this, one may set the option
|g:tex_flavor| in ones `vimrc` file, that is: >

  let g:tex_flavor = 'latex'

Vimはすぐに使えるようにいくつかのLaTeXサポート機能が同梱されています。とりわけ、すぐれたシンタックスハイライト(ft-tex-syntax)、インデンテーション、気の利いたオプション(ft-tex-plugin)を提供しています。

vimtexがアクティブならば、メインのファイルタイププラグインとして使用されます。これは内部プラグインの気の利いた設定と同等のことを定義します。けれども、vimtexは独自のシンタックスを提供する代わりに、ft-tex-syntaxにいくつかの些細な改良を加えています。vimtexはまた独自のインデンテーションを提供しています(vimtex-indent)。

Vimは一般的にファイルタイプを自動的に検出します。ほとんどの場合これは期待通りに動作しますが、いくつかの場合には"tex"拡張子のファイルタイプをplaintexと検出してしまいます。これを防ぐには、g:tex_flavorオプションを設定すると良いかもしれません。

とのことです。
ところがこれをやってみても、どうにもうまく検出してくれません。もしかしたらvimtexのオプション設定でどこかミスがあって、それがvimtexモードになるのを阻害しているのかもしれませんが…。

vimtexの便利な機能が使えないのは結構困るのですが、とりあえず保存するたびにコンパイルしてくれるようにしたいので、以下のようにしました。

latexmk -pvc -view=none %1
というバッチファイルを作成し、ルートtexファイル(\includeなどでいくつかのファイルを読み込んでいる場合の一番親ファイル)を食わせると、子ファイルに変更があったときでも自動でコンパイルを始めてくれます。

それからこんな記事を見つけました。
Writing LaTeX in Neovim with Vimtex
あとで読んでみようと思います。

Neovim+vimtexでのテキストアライン。

テキストアライン、あるいは桁揃えですが、Vim/Noevimでもいくつかのプラグインがあります。Align とか vim-easy-align とか。

ただ、自分で使ってみた感じでは godlygeek/tabular が使いやすかったので、これの使い方をメモです。

tabularでは、範囲指定したうえでどの文字を桁揃えに使用するかを正規表現で指定します。

たとえば現在行から5行分を、'&'文字で桁揃えしたい場合には、
:.,+5Tab /&
とします。この場合、各カラムは左寄せです。

','で区切られた各カラムを中央寄せにし、前後に最低1文字以上のスペースを入れる場合には、
:Tab /,/c1
とします。

','で区切られた各カラムを右寄せにし、','との間に1文字の空白を入れる場合には、
:Tab /,/r1
とします。

桁揃えの指定は正規表現なので、
:Tab /[,|&]
などとすれば ',''|''&'の3つの文字を桁区切りに指定できます。

vimtexのfoldカスタマイズ。

lervag/vimtexで、foldingを有効にしてみたら文書の見通しがよくなったので、自分的カスタマイズとその他のメモなど。

\section や \subsection、あるいは itemize や description、lstlisting などの部分を折りたたむことができれば、文書の構成がより把握しやすくなるし、編集もしやすくなってくるので、なにを折りたたむかの設定やキーマップなどをざっくりとまとめます。

まず vimtex の構成として、折りたたみ動作は fold.vim がやっているようです。その中のvimtex#fold#init_buffer() を見ると、ある程度の初期化がされているのがわかります。つらつら見ていくとどういう構造で折りたたもうとしているのかがおおよそわかります。

折りたたみはデフォルトでは無効になっているので、これを有効にしてやればまずは折りたたみができるようになります。

let g:vimtex_fold_enabled = 1

g:vimtex_fold_manual = 1にすると、デフォルトで折りたたみ処理を行わない状態でファイルを開きます。大きいファイルをよく扱うような場合に、ファイル読み込みが遅くなるのを回避します。このとき、キーマップ zx と zX がリマップされます。

折りたたみの操作は以下の通り。詳細については :h fold を参照。
  • zo カーソルの下の折りたたみを1段階開く。カウントが与えられればカウント数分開く。
  • zO カーソルの下の折りたたみをすべて開く。
  • zc カーソルの下の折りたたみを1段階閉じる。カウントが与えられればカウント数分閉じる。
  • zC カーソルの下の折りたたみをすべて閉じる。
  • za カーソルの下の折りたたみが閉じていれば開く。開いていれば閉じて、foldenableをセットする。
  • zA カーソルの下の折りたたみが閉じていれば再帰的に開く。開いていれば再帰的に閉じて、foldenableをセットする。
  • zm 折りたたみをより閉じる。foldenableをセットする。
  • zM すべての折りたたみを閉じる。foldenableをセットする。
  • zr 折りたたみをより開く。
  • zR すべての折りたたみを開く。
なにを折りたたむかは g:vimtex_fold_types で指定します。基本的には、g:vimtex_fold_types_defaultsで設定されている既定値を必要に応じて上書きします。定義は辞書の形式で行い、{キー:値}で定義していきます。

vimtex のヘルプファイルからキー(と値)の解説から一部引用して加筆翻訳しておきます。
  • 'preamble'
    プリアンブルを折りたたむかどうか。
    • { 'enabled' : 0/1 } -- 0:折りたたまない 1:折りたたむ
  • 'comments'
    複数行のコメントを折りたたむかどうか。デフォルトは無効。
    • { 'enabled' : 0/1 } -- 0:折りたたまない 1:折りたたむ
  • 'envs'
    環境を折りたたむかどうか。'document'環境は折り畳まれない。
    • { 'blacklist' : [] } -- 折りたたまない環境のリスト。正規表現が使える。
    • { 'whitelist' : [] } -- 折りたたむ環境のリスト。正規表現が使える。
  • 'envs_options'
    環境のオプション(複数行などの長いもの)を折りたたむかどうか。
    • { 'enabled' : 0/1 } -- 0:折りたたまない 1:折りたたむ
  • 'sections'
    section とパートを折りたたむかどうか。以下のキーがある。
    • { 'parse_levels' : 0/1} -- vimtex-toc で表示されるような感じでレベルを解析して折りたたむかどうか。デフォルトは 0。有効にするとリソースを食うし遅くなる。
    • { 'sections' : [] } -- 折りたたみする section のリスト。リストには正規表現が使える。デフォルトは [ 'part', 'chapter', 'section', 'subsection', 'subsubsection' ]
    • { 'parts' : [] } -- 折りたたみをするパートのリスト。リストには正規表現が使える。デフォルトは [ 'appendix', 'frontmatter', 'mainmatter', 'backmatter' ]
あとの詳細はヘルプファイル参照。 とりあえず以下の設定を使います。
let g:vimtex_fold_types = {
  \  'envs' : {
  \   'whitelist' : ['table', 'lstlisting'],
  \  },
  \  'comments' : {'enabled' : 1},
  \}

let g:vimtex_fold_enabled = 1

風車の速度。

知人と話をしていて、ちょっと風が強いね、あの風車ものすごい勢いで回ってるね、という話から、江東区若洲あたりの風力発電設備のタービンの話になりました。

若洲風車の施設案内によれば、風車はドイツのノルバデックス社製で、モータの高さは地上 60m、タービンブレードの長さは 40m とのこと。

以前に若洲に行ったときに実測したところ、風速 10m 程度で 1 分間に 17 回転。17rpm です。

すると円周は\(40\times 2\times\pi=251\)m。これが17rpmなので、時速になおすと\(251\times 17\times 60\div 1000=256.35\)km/h。地上20m の位置を、ブレードの先端が 250km/h のスピードで通り過ぎるわけです。

記憶によればこのときはそれほど強い風が吹いているというわけでもなかったので、もうちょっと強い風が吹くと簡単に 300km/h 以上になりそうです。

ちなみに風速 25m/s で回転は停止するそうですが、そのときには 30rpm くらい(2秒で1回転)くらいはしてるんでしょうか。計算すると先端速度は 450km/h を超えます。

至近距離でそれだけの速度のものを見ることができるのはここかもしれません。

VirtualBoxの不具合。

Linuxの現物PCではある程度確認の取れた設定を行いたいので、別途VirtualBoxでサンドボックスを作ってそちらで動作確認や設定のテストなどを行っているのですが、どうもVirtualBoxの拡張パックが5.2.22ではちゃんと動くのに5.2.24以降では動作がおかしくなる不具合があるようです。特定の環境のみで出るのか、それとも一般的なものなのかはわかりませんが、VirtualBox 6.0 guest additions problemで Manjaro での不具合が報告されています。
But the shutdown and startup take much longer time (close to 1 minute) with a message like “A start job is running vboxadd.services” or “A stop job is running vboxadd.services”. I checked under /var/log there seems to be a vboxadd_setup.log on every startup, which perhaps means that the guest additions module is rebuilt on every startup?

The system runs well on VBox 5.22 and earlier.
内容としては、起動時及び終了時に vboxadd.service が異常に時間がかかる、というものです。自分のところでも数分近くかかっていました。
どうもいろいろぐぐってみると、VBoxAddtionsあたりはけっこうトラブルが多いようですね。

VirtualBoxの最新バージョンは5月14日の6.0.8なのですが、そちらでもおかしいから5.2.22に戻しています。ただ、毎回起動するたびに「新しいバージョンがあります」メッセージが出るのが鬱陶しいですね。

\(\rm\LaTeX\)のテーブル環境。

いくつかの項目をわかりやすく並べて比較できるようにするのに、表形式は便利です。

\(\rm\LaTeX\)ではいくつかのテーブル環境が用意されています。CTANでざっと検索しただけでも、lxtable、stabular、ltablex、tabu、supertabular、longtable、tabularxなどがあります。

昔使っていたときには、次のページに続くような長い表になったり、表のレイアウト位置を指定したりするのに supertabular 環境を利用していたのですが、現在は longtable 環境に引き継がれているようです。tabularx はカラム幅を指定したり自動的に拡張できる X オプションを持ったもので、lxtable や ltablex は tabluarx と longtable の機能を組み合わせたものです。

この中でどれか一つを選ぶとしたら、tabu を選べばよいでしょう。tabu は単一ページのテーブル環境の tabu と、マルチページテーブルの longtabu の2つの環境を持ち、色分けや表の入れ子などにも対応できます。tabu は array や xcolor、longtable などを外部参照することで機能を実現しているので、それらは別途明示的に usepackage する必要がありますが、大抵のことはできそうです。

tabu 環境についてはちょっと検索してみてもあまり解説しているページが引っかかりません。ドキュメントは \texlive\2019\texmf-dist\doc\latex\tabuにPDFがあるので、これを参考にすればいいでしょう。

Windows 10 1903の初期不具合。

Windows 10 バージョン1903がリリース。の続報ですが、窓の杜から、「Windows 10 May 2019 Update」には既知の不具合が12件 ~手動更新には十分注意だそうです。

上記ページに不具合のざっくりした説明もありますが、いまのところうちでは無関係かな、という内容です。
ただ、リリース後2日でこれだけ出たのと、うちにはまだ配信されていませんがこれから範囲が広がってくるともっとボロボロと出てきそうですし、バグ曲線(信頼度成長曲線)的に収束するにはひと月くらいは様子見したほうがいいのかな、という感覚です。急がないのであれば7月から8月までは待ったほうがいいかもしれません。

Windows 10 バージョン1903がリリース。

Windows 10 のアップデート May 2019 がリリース開始されたようです。「Windows 10 May 2019 Update」(ビルド1903)一般提供開始に詳細が出ています。記事中では 1903 ではなく 1809 となっている部分がありますが、どうやら 1903 で間違いないようです。
が、あながち間違いというわけでもないようで、「Windows 10 May 2019 Update」が一般公開 ~順次展開へによれば、Windows Update で 「April 2018 Update(バージョン 1803)」と「October 2018 Update(バージョン 1809)」をインストールして、さらに KB4497934 の累積アップデート(2019-05 x64 ベース システム用 Windows 10 Version 1809 の累積更新プログラム (KB4497934))もインストールしている必要があるようです。現在のバージョンが 1809 の Windows 10 のみでこのアップデートの更新ボタンが出てくるようです。


以前からちょっと話題になっていたようですが、1903 は Insider 向けにすでにリリースされていて、その中でちょっと大きい変更として WSL 2 が含まれています。
WSL 2 は Hyper-V を利用して、Windows 上で Linux kernel を動かすようで、これは Docker なども使っている技術という理解でよいでしょうか。Microsoft、「WSL 2」への質問にブログで回答にいくつかの質疑応答がまとめられています。

Hyper-V を有効にすると VirtualBox は動かなくなるので、これは必要な人のみということになるでしょう。Sandbox として VirtualBox を使う必要がある人は Hyper-V はおあずけですね。

ちなみに自分の PC にはまだアップデート通知が来ていません。

BloggerのSyntaxHighlighterにLaTeXのbrushを入れてみる。

主観情報処理研究所さんのSyntaxhighlighter関連TipsにSyntaxHighlighterのLaTeX用Brushがあるよという情報があったので、うちでもBloggerに適用してみました。

\documentclass[uplatex,dvipdfmx,ja=standard,a4paper]{bxjsarticle}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[dvipdfmx]{graphicx}
\usepackage{hyperref}
\usepackage[dvipdfmx]{pxjahyper}
\usepackage{comment}

\setlength{\parindent}{0pt}
\setlength{\parskip}{2ex plus 0.5ex minus 0.2ex}

\begin{document}
こんにちは、世界。
\end{document}

ほほう。

やったことは、以下の通り。

LaTeX for SyntaxHighligther 3のページから、jsへのリンクへ飛んで、ソースをクリップボードにコピーします。

BloggerのテーマでHTML編集を開いて、"/head" の前に <script>(コピーした内容を貼り付け)</script> を入れて保存。

class指定で "brush:latex" する。

です。

listingsとfancyvrb。

\(\rm\LaTeX\)でソースコードや設定を記述するときに、listings パッケージ + jlisting パッケージを使って貼り付けていましたが、"//"コメントを使うとイタリック体になってしまって都合が悪いことに気づきました。まあ気にしない人は気にしない程度のことかも知れませんが。

追記: listingsのドキュメントを見ていたら、commentstyle という key のデフォルトが itshape になっているのを見つけました。
lstset の中で書体を指定すればイタリック体以外も使えます。


実は description 環境を使ったときに、段落間をもうすこし開けたい、と調べているときに fancyvrb パッケージを発見して、これを見てみたらすごくいい感じだったのでメモです。

fancyvrbパッケージでは、通常の verbatim 環境を拡張して、文字の色付け、枠囲い、フォントの指定、空白文字の表示などなど、いやそれ verbatim じゃないだろうと思ってしまうような指定がいろいろできます。さらには verbatim 内で \fboc{}や \textcolor{}などが使え、なんだそりゃ的にすごいので、verbatim なんだけどこの行だけ特に強調したい、みたいな場合にはすごく助かります。詳細は上記リンク参照。

追記: Verbatim環境で、UTF-8で「対応」の文字が "Invalid code (24540), should be in the range of 0..255." というエラーになりました。up-\(\rm\LaTeX\)なので中身はe-up\(\rm\TeX\)なんですが、日本語で listings+plistings(jlisting) のほうがいいかもしれません。

ちなみに description 環境で \item 内の記述の段落間をもう少し開けたい場合には、enumitem パッケージを使います。enumitem パッケージはリスト系の環境の書式を、topsep、partopsep、parsep、itemsepで調整できます。
\begin{description}[topsep=0pt,partopsep=0pt,parsep=15pt,itemsep=0pt]
    \item [first item]~\\
        1行目。

        2行目。
    \item [second item]~\\
        なんとかかんとか。
\end{description}
みたいな感じで使うと、1行目と2行目の間を15pt分開けてくれます。

それから余談ですが、listings パッケージの日本語対応で jlisting を使うというのはよく見るのですが、plistingというのもあるようです。
よくよく見てみると、jlisting.sty を使うという記述のページでは、jlisting.sty の入手先を SourceForge の My\(\rm\TeX\)part の奥の方から URL 直で指定しているようですが、My\(\rm\TeX\)part の wiki では Listingsのページで plistings を推してるじゃありませんか。
plistings は GitHubの方には、e-\(\rm\TeX\) 拡張必須、と記載がありますが、TeXLive はすでに up\(\rm\LaTeX\)などはe-\(\rm\TeX\)なので、問題ナッシングです。

もうひとつ、listing の lstset で language を指定するときに、サポートしている言語のリストってどこー、とか探してもなかなか見つからないので列挙しておきます。

ABAP (R/2 4.3, R/2 5.0, R/3 3.1, R/3 4.6C, R/3 6.10)、ACM、ACMscript、ACSL、Ada (2005, 83, 95)、Algol (60, 68)、Ant、Assembler (Motorola68k, x86masm)、Awk (gnu, POSIX)、bash、Basic (Visual)、C (ANSI, Handel, Objective, Sharp)、C++ (11, ANSI, GNU, ISO, Visual)、Caml (light, Objective)、CIL、Clean、Cobol (1974, 1985, ibm)、Comal 80、command.com (WinXP)、Comsol、csh、Delphi、Eiffel、Elan、erlang、Euphoria、Fortran (03, 08, 77, 90, 95)、GAP、GCL、Gnuplot、hansl、Haskell、HTML、IDL (empty, CORBA)、inform、Java (empty, AspectJ)、JVMIS、ksh、Lingo、Lisp (empty, Auto)、LLVM Logo、Lua (5.0, 5.1, 5.2, 5.3)、make (empty, gnu)、Mathematica (1.0, 3.0, 5.2)、Matlab、Mercury、MetaPost、Miranda、Mizar、ML、Modula-2、MuPAD、NASTRAN、Oberon-2、OCL (decorative, OMG)、Octave、Oz、Pascal (Borland6, Standard, XSC)、Perl、PHP、PL/I、Plasm、PostScript、POV、Prolog、Promela、PSTricks、Python、R、Reduce、Rexx、RSL、Ruby、S (empty, PLUS)、SAS、Scala、Scilab、sh、SHELXL、Simula (67, CII, DEC, IBM)、SPARQL、SQL、tcl (empty, tk)、TeX (AlLaTeX, common, LaTeX, plain, primitive)、VBScript、Verilog、VHDL (empty, AMS)、VRML (97)、XML、XSLT

自分が使いそうなのだけ色を変えてみました。ふと気づけば Windows PowerShell がないですね。

それから listings のドキュメントを眺めたら、Interface to fancyvrb というのがありました。

The fancyvrb package—fancy verbatims—from Timothy van Zandt provides macros for reading, writing and typesetting verbatim code. It has some remarkable features the listings package doesn’t have. (Some are possible, but you mustfind somebody who will implement them ;-).

fancyvrb=[true|false]
activates or deactivates the interface. If active, verbatim code is read by fancyvrb but typeset by listings, i.e. with emphasized keywords, strings, comments, and so on. Internally we use a very special definition of \FancyVerbFormatLine.
This interface works with Verbatim, BVerbatim and LVerbatim. But you shouldn’t use fancyvrb's defineactive. (As far as I can see it doesn’t matter since it does nothing at all, but for safety ....) If fancyvrb and listings provide similar functionality, you should use fancyvrb's.

listings のオプションで fancyvrb=true すると、verbatim 自体は facyvrb が行うけどタイプセットは listings が行う、と。つまり、fancyvrb の Verbatim 環境の中でキーワードや構文強調などが使えるということのようです。

また、listings でサポートされていない言語を追加する場合には(たぶんいろいろと解説してくれているサイトもあるでしょうが)、
\lstdefinelanguage{rock}
{
  morekeywords={one,two,three,four,five,six,seven,eight,
      nine,ten,eleven,twelve,o,clock,rock,around,the,tonight},
  sensitive=false,
  morecomment=[l]{//},
  morecomment=[s]{/*}{*/},
  morestring=[b]",
}
みたいな形でプリアンブルに追加できるようです。

VSCodeのLaTeX WorkshopとVscodeVim。

ちょっと不思議というか。

Visual Studio Code で LaTeX ファイルを編集して、LaTeX Workshop の設定では、
  • Latex > Auto Build: Run = ofFileChange
  • Latex > Auto Build: Interval = 1000
などとしているんですが、Vim(VscodeVim)を有効にしていると、":w" で保存したときにトリガーがかからず、自動ビルドが始まってくれません。

LaTeX Workshop のドキュメントを見ると、

"onFileChange": Build the project upon detecting a file change in any of the dependencies. The file can even be modified outside vscode. See here for explanations on what dependencies are and how some of them can be ignored.

とあるので、依存関係にあるファイルが「vscode の外部で」変更されても検出してコンパイルするよ、ということらしいのですが…。

ちなみに "Build LaTeX project" のキーバインドは C-A-b のようですが、ちょっと使いづらい感じ。VimTeX と共通で '\ll' としたいところですが、
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["\\", "l", "l"],
      "commands": [
        "latex-workshop.latex.recipe.default",
      ]
    }
  ],
としてもうまく動きません。まあ、C-A-b でもいいんですけど…。

NetBSDでlibuvがコンパイルできない件。

自分用メモです。

NetBSD-8 で Neovim の master ブランチをビルドしようとしたら、libuv で
~/build/neovim/.deps/build/src/libuv/src/unix/thread.c:222:22: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
     if (stack_size < PTHREAD_STACK_MIN)
                      ^
というエラーが出て、コンパイルできませんでした。 ちょっと調べてみると、/usr/include/limits.h
/*
 * These are the correct names, defined in terms of the above
 * except for PTHREAD_KEYS_MAX which is bigger than standard
 * mandated minimum value _POSIX_THREAD_KEYS_MAX.
 */
#define PTHREAD_DESTRUCTOR_ITERATIONS   _POSIX_THREAD_DESTRUCTOR_ITERATIONS
#define PTHREAD_KEYS_MAX                256
/* Not yet: PTHREAD_STACK_MIN */
#define PTHREAD_THREADS_MAX             _POSIX_THREAD_THREADS_MAX
という部分があり、確かに定義されていません。 さらに調べてみると、NetBSD の tech-userlevel メーリングリストで2014年にPTHREAD_STACK_MINというメールが投げられていました。そこでの結論は、 PTHREAD_STACK_MINの代わりにsysconf(_SC_THREAD_STACK_MIN)を使ったほうが安全、ということのようです。 一方 libuv のほうでは、今年の4月に Do not use PTHREAD_STACK_MIN unconditionally for the unix target #2252というのが出ており、結果として「定義されていれば使用する」という形に落ち着いたようです。途中、GNU じゃない FreeBSD とか NetBSD は libuv はサポートせんよ、みたいな投稿もありましたが。

ともあれ、現状では Neovim の CMake では libuv-1.26.0(2019年2月11日リリース)を使用しているようで、1.29.0 では上記の変更が反映されているようなので、そのうち修正なしでコンパイルできるようになるでしょう。

Neovim でのコンパイルにおいては、最初にある thread.c に #2252 のパッチを当てればいいかと思います。

BIND 9のdnssec-lookasideの設定。

BIND 9(9.14.1)の named.conf をいじってるんですが、named-checkconf をかけると次のメッセージが出てきます。
# named-checkconf
/etc/named.conf:10: dnssec-lookaside 'auto' is no longer supported
え、どういうこと?と思って調べてるんですが…。

9.12.0 のリリースノートに以下の記述がありました。
The ISC DNSSEC Lookaside Validation (DLV) service has been shut down; all DLV records in the dlv.isc.org zone have been removed. References to the service have been removed from BIND documentation. Lookaside validation is no longer used by default by delv. The DLV key has been removed from bind.keys. Setting dnssec-lookaside to auto or to use dlv.isc.org as a trust anchor results in a warning being issued.
ISC.org の DNSSEC Lookaside Validation(DLV)サービスが停止されて、dlv.isc.org にあるすべての DLV レコードが削除されたので、dnssec-lookaside autoしたり dlv.isc.org を trust anchor に指定すると、警告が出ますよ、と。

BIND 9.12.0 は 2018年1月にリリースされています。それに先駆けて、上記のサービスが2017年9月30日に停止されています。ISC's DNSSEC Look-aside Validation Registry

要するに、trust anchor を別のところに設定すればいいということだと思うのですが、一応参考までに最新のトラストアンカーによるDNS検証リゾルバの更新

NeovimをVisual Studio 2019でコンパイルする。

以前にNeovimをVisual Studio 2017でコンパイルする。を書いていますが、ちょうど1年経ったことでもあるので、アップデートしてみます。
前提条件ですが、うちでは c:/Apps/Neovim 以下にインストールしていますので、新規ビルドは c:/Apps/Neovim-new にインストールしてから最後にディレクトリ名を変更する形にします。

Neovimをコンパイルする

CMakeのおかげもあって、ものすごく楽になっています。
以前にあった C4819 警告(データの損失を防ぐために、ファイルを Unicode 形式で保存してください。)は出ますが、これは 「ベータ: ワールドワイド言語サポートでUnicode UTF-8を使用(U)」をセットしておくか、Windowsのシステムロケールを「英語(米国)」に変更しておくことで回避できます。お勧めは後者のシステムロケールの変更です。
$ git clone https://github.com/neovim/neovim
$ cd neovim
neovim$ make CMAKE_BUILD_TYPE=Release CMAKE_INSTALL_PREFIX=c:/Apps/Neovim-new
で依存ライブラリまで含めてすべてビルドしてくれます。
ビルドが終わったら
neovim$ make install
です。

Neovim-Qtをコンパイルする

equalsraf/neovim-qtは活発な開発という段階は終わって、API への対応があるくらいでほぼ安定ということなのでしょう、最後のコミットも3ヶ月以上前です。
ただ、Neovim の Windows バイナリに同梱されている Neovim-Qt は 32bit 版なので、好みの問題でしょうが 64bit 版をコンパイルします。

README.mdには
$ mkdir build
$ cd build
$ cmake -G "Visual Studio 14" -DCMAKE_BUILD_TYPE=Release ..
$ cmake --build . --config Release --target install
とありますが、自分の環境ではこれだけではコンパイルできないのでまとめです。

Qt5 は c:\Apps\Qt\ 以下にインストールしています。バージョンは 5.12.2 で、C:\Apps\Qt\5.12.2\msvc2017_64\binをパスに追加しています。これがないと WinDeployQt.exe を見つけられなくてエラーになります。

また CMake は 3.14.4 でパスを通しています。
$ git clone https://github.com/equalsraf/neovim-qt
$ cd neovim-qt
neovim-qt$ mkdir build
$ cd build
build$ set CMAKE_PREFIX_PATH=C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Core;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Gui;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Svg;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Network;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Widgets;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Test
build$ cmake -G "Visual Studio 16" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=c:/Apps/Neovim-new ..
build$ cmake --build . --config Release
ここで msgpack-cpp-3.0.1 が C2220 エラーを出してビルドがエラー終了します。なので CMakeLists.txt にパッチを当てます。
neovim-qt$ diff -rub third-party/CMakeLists.txt.orig third-party/CMakeLists.txt
--- third-party/CMakeLists.txt.orig     Sat May 18 09:56:59 2019
+++ third-party/CMakeLists.txt  Sat May 18 09:53:11 2019
@@ -13,17 +13,17 @@
 set(MSGPACK_URL https://github.com/msgpack/msgpack-c/archive/cpp-${MSGPACK_VERSION}.tar.gz)
 set(MSGPACK_SHA256 1b834ab0b5b41da1dbfb96dd4a673f6de7e79dbd7f212f45a553ff9cc54abf3b)

-message(STATUS "Downloading Msgpack...")
-set(MSGPACK_TARBALL msgpack-${MSGPACK_VERSION}.tar.gz)
-file(DOWNLOAD ${MSGPACK_URL} ${CMAKE_CURRENT_SOURCE_DIR}/${MSGPACK_TARBALL}
-       INACTIVITY_TIMEOUT 30
-       EXPECTED_HASH SHA256=${MSGPACK_SHA256})
-execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${MSGPACK_TARBALL}
-       WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
-       RESULT_VARIABLE rv)
-if(NOT rv EQUAL 0)
-  message(FATAL_ERROR "Failed to extract ${MSGPACK_TARBALL}")
-endif()
+#message(STATUS "Downloading Msgpack...")
+#set(MSGPACK_TARBALL msgpack-${MSGPACK_VERSION}.tar.gz)
+#file(DOWNLOAD ${MSGPACK_URL} ${CMAKE_CURRENT_SOURCE_DIR}/${MSGPACK_TARBALL}
+#      INACTIVITY_TIMEOUT 30
+#      EXPECTED_HASH SHA256=${MSGPACK_SHA256})
+#execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${MSGPACK_TARBALL}
+#      WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+#      RESULT_VARIABLE rv)
+#if(NOT rv EQUAL 0)
+#  message(FATAL_ERROR "Failed to extract ${MSGPACK_TARBALL}")
+#endif()

 set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR})
 set(MSGPACK_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/msgpack-c-cpp-${MSGPACK_VERSION}/)
上のパッチを当てておかないと、修正しても上書きされてしまいます。
neovim-qt$ diff -rub third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt.orig third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt
--- third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt.orig Sat May 18 09:57:13 2019
+++ third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt      Sat May 18 09:53:42 2019
@@ -251,9 +251,9 @@

 IF ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
     IF (CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
-        STRING(REGEX REPLACE "/W[0-4]" "/W3 /WX" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+        STRING(REGEX REPLACE "/W[0-4]" "/W3" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
     ELSE ()
-        SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W3 /WX")
+        SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W3")
     ENDIF ()
 ENDIF ()
また、ソースの方では test/tst_neovimconnector.cpp が文字コードの関係でエラーになります。
neovim-qt$ diff -rub test/tst_neovimconnector.cpp.orig test/tst_neovimconnector.cpp
--- test/tst_neovimconnector.cpp.orig   Sat May 18 10:40:47 2019
+++ test/tst_neovimconnector.cpp        Sat May 18 12:00:12 2019
@@ -40,7 +40,7 @@
                NeovimConnector *c = NeovimConnector::spawn({"-u", "NONE"});

                // This will print a warning, but should succeed
-               QString s = "ç日本語";
+               QString s = "nihongo";
                QByteArray bytes = c->encode(s);
                QCOMPARE(c->decode(bytes), s);

そうしたらビルド&インストールします。Neovimよりもあとにインストールすることで、32bit バイナリも上書きしてくれます。
build$ cmake --build . --config Release --target install
実際には本来不要なものまでインストールされますが、気になる場合には本家のビルドとファイルを比べて削除すればよいでしょう。

電気シェーバーの手入れ用オイル。

手入れ用のオイルやグリースはいろんな種類があります。

一般の家庭では、たぶんいちばん身近なものはミシン油でしょうか。あとは潤滑油という分野では CRC 5-56 あたりかも。5-56 は自転車乗り界隈では「緊急時以外は使ってはいけない」潤滑油として有名です。チェーンルブやベアリングのグリースを溶かして落としてしまうので、うちでは一切使っていません。固着したネジやナット部分にスプレーしてしばらく置くと浸透して緩めやすくなるので、そういう用途ではいいでしょう。ただ、揮発しやすいので長期的な潤滑はまったく期待できません。

それはいいとして、電気シェーバー用のオイルです。オイルなのにひげそりのような敏感な用途に使ってもいいんだろうかと思って成分を見てみたら、流動パラフィンと書いてありました。
最も身近な物がベビーオイルである。常温では無色の液体で非揮発性。水には不溶。化学的に安定な物質で、通常の条件では酸化を受けない。成分については固形のパラフィンよりオレフィン系炭化水素に富む。乳化しやすくのびや浸透性に優れる。純度は紫外光の吸光度により計測される。
たしかに、ベビーオイルも「オイル」という名前です。なるほど。それならカミソリ負けしやすい敏感肌でも大丈夫そうです。となると、パナソニック純正のシェーバー用オイルが 50ml で数百円しているのですが、ジョンソンベビーオイルでも兼用できるということですね。

Mercurial 5.0リリース。

Git というかおそらくは Github に圧倒されてる Mercurial ですが、当初のアナウンス(5月1日リリース)から1日遅れの5月2日に 5.0 がリリースされたようです。PyPi のほうは最新版が 5.0 になっています。

ただ、Mercurial Wiki の Python3を読むと、
Mercurial's setup.py file refuses to run with Python 3 by default. This means that pip install Mercurial or python setup.py install will not work with Python 3 by default.

Setting the HGPYTHON3 environment variable will suppress this error and allow execution with Python 3. e.g. HGPYTHON3=1 pip3.7 install Mercurial or HGPYTHON3=1 python3.7 setup.py install.

No run-time environment variable or config option is required to use Python 3 with Mercurial: only the installation step / setup.py requires special action to override the Python version check.
Python3 はデフォルトでは拒絶されるようになってるので、HGPYTHON3=1 してインストールすると有効になるよ、とのことです。

一方、TortoiseHG はまだ 4.9.1 が最新のようですが、5.0 に向けての作業は進んでいるようです。

ただ、Windows で使用するにはファイルシステムのエンコーディングあたり(PEP 529)でまだ難があるのか、あとは lazy importer のあたりでパフォーマンスに影響がないかなどをよく見る必要がある、みたいなことが書いてあります。

とりあえず現在進行中のプロジェクトでは 5.0 にあげないほうが無難でしょうね。
ただ、Mercurial が Python 3 で動くなら Python 2.x はもう排除できてありがたいので、ここは考えどころですね。

WindowsロケールをUTF-8にして不具合のあるアプリ。


Windowsの設定で UTF-8 をデフォルトにすることができるようになって 1 年以上が経ちますが、ここらへんでどういうアプリに影響があるかを自分の使ってる範囲でまとめてみます。

地域と言語の設定で「システムロケールの変更」をクリックすると、「地域の設定」ダイアログが出ますが、そこに「ベータ: ワールドワイド言語サポートでUnicode UTF-8を使用(U)」という項目があります。これは昨年の11月14日のInsider Previewで出てきたようです。/.Jより、Windows 10のInsider PreviewでシステムロケールをUTF-8にするオプションが追加されるによれば、
  • 圧縮 (zip形式) フォルダーにファイル名がUTF-8で保存されるようになった。これに伴い、シフトJISに含まれない文字を使ったファイル名も普通に保存できるようになった。
  • コマンドプロンプトのコードページが既定で65001(UTF-8)になった。このときのWindows標準コマンドのメッセージは英語になる。
  • メモ帳のテキストエンコーディングがUTF-8になった。なお「ANSI」を選んでもUTF-8で保存されるので、シフトJISでの保存はできなくなる模様。
  • GetACP()の戻り値も65001になる。WideCharToMultiByteなどでCP_ACPを指定したときも、UTF-8に変換される。
だそうです。

影響のあるアプリ

明らかにメニューやダイアログが文字化けして正常に使用できないものです。
  • TeraTerm: ダイアログ、メニューバーなどほぼすべての日本語部分が文字化けする。ソースレベルでリソースファイルが ShiftJIS となっている。
    追記(2019/5/14): teraterm\lang\Japanese.lng を UTF-8 に変換してやればGUIの文字化けは解消される。
  • Python 2.7: コンソールでの文字の扱いでおかしなことになる。例: print "あ" で止まる。
  • Python 3.6: Python 2.7 と同様におかしなことになる。例 print("あ")
  • Python 3.7: Python 2.7 と同様におかしなことになる。例 print("あ")
  • cmd.exe: フォントがデフォルトの Consolas だと文字化けする場合がある。現在は修正されている?ただし、dir /?などのヘルプ関連はすべて英語になる。これは PowerShell も同様。
  • Becky! 2: 表示はできるが、自動振り分けで失敗する。
  • 筆王 Ver.23: スプラッシュスクリーンは表示するが起動しない。インストールも失敗する。
Python については、PYTHONIOENCODING=utf-8 を環境変数に設定してやればよいという記述も見たのですが、どうもうまくいきませんでした。どちらも IDLE が起動しません。コマンドラインから起動してみると、
UnicodeDecodeError: 'CP_UTF8' codec can't decode byte 0x8c in position 23: No mapping for the Unicode character exists in the target code page.
というエラーが出るので、ダメ文字関連(ShiftJISの2バイト目が '0x5c' の文字 - 'ー ソ 十 表'など)でしょうね。特にメニューに「表示」などが使われるとてきめんです。

影響のないアプリ

外見上は影響がないように思えるのは以下のものです。
  • 秀丸エディタ
  • Visual Studio Code
  • Notepad++
  • Neovim: ロケールを ja_JP.UTF-8 と設定してやれば GuiFont に日本語フォント名が使える。
  • Sylpheed
  • TortoiseHG: 以前はPythonでの不具合があった(LookupError: unknown encoding: cp65001)が、修正されているように見える。
  • FreeCAD
  • LibreCAD
  • Blender
  • Inkscape
  • Krita
  • Canon Digital Photo Professional
  • Adobe Reader XI
  • SumatraPDF
  • CubePDF
  • AviUtl: 以前はメニュー類、プラグインのダイアログなどが文字化けしていたが、(おそらくシステム側で?)修正されている模様。
  • MuseScore 2

NetBSDとBIND 9。

ふと、インターリンクで IPv6 に対応しているから、じゃあやってみるためにちょっと調べようと思いまして。

うちは 光ルーターとして RS-500KI を使っています。この場合、インターリンクに接続するとここで示唆されている通り、.hgw6 が付加されて接続できません。そしてこの設定はユーザがいじることができません

であれば、光ルーターはただのブリッジにして、内側には Aterm WG1900HP があるのでそれを使って IPv6 PPPoE してやればできるんじゃないかと思ったわけです。いずれにしてもインターリンクは IPoE はやっていないので、だれかが PPPoE してやればいいわけです。当然ながらフレッツ・v6オプションは有効になっています。

と、周囲の状況を確認した上で、さてネームサーバはどうしましょう、と。
NetBSD は 1.3 の頃にいじり始めて、サーバとしてドメインをとって BIND とかをいじり始めたのは 2003年以降だったと思いますが、当初は ADSL 回線でした。当時は DNS サーバは WAKWAK 側で用意していたので、こちらでは権威サーバではなくローカルの名前解決用として使うくらいでした。
その後、インターリンクにプロバイダを切り替えたのは独自ドメインが安く取得できるからという理由です。最近はさくらインターネットなどでも安価に運用できるようになっていますが、おうちサーバを立てるなら全部自分でやってね、プライマリネームサーバもね、というスタンスのインターリンクはやる気になればいろいろできるので便利です。サブドメインや仮想ホスト(CNAME)も作り放題ですし。

ということでネームサーバですが、BINDの設定を見ていて、そういえば /usr/share/example に IPv6 の設定例みたいなのがあるのでは、と探してみたところ、bind のサンプルが収録されていません。変だな、と思って他のサンプルを見てみると、nsd と unbound があります。おや?と不審に思って検索してみたら、2016年8月に bind -> unbound/nsd というメールが christos 氏から投げられていて、ISC が BIND のライセンスを変更したから、NetBSD に収録する DNS サーバの変更を検討したほうがいいんじゃね?と提起されていました。その結果、おそらく BIND は積極的には使わない方向にいっているのかもしれません。

ともあれ BIND の設定サンプルはないようだし、BIND の設定は面倒だし、もうちょっと楽にできないかしらというのもあって、NSDUNBOUND が採用されたようだし、みてみることにしました。

NSD も UNBOUND もどちらも NLnet Labs の製品で、NSD は権威サーバ、UNBOUND はキャッシュ&リゾルバです。それ以外には packages に PowerDNSもあります。

とりあえず、本家の流れに従って、BIND から NSD/UNBOUND に移行してみましょうか。

From Bind to nsd and unbound on OpenBSD 5.6を参考にすると、NSD では BIND の ZONE ファイルをそのまま使えるようです。であれば権威サーバの移行はスムーズです。
ArchLinux の Wiki にも NSDUNBOUND のページがあります。また、日本 Unbound ユーザ会が日本語ドキュメントを用意してくれています。ちなみに NetBSD-8 の base.tgz には nsd は含まれていませんが、ソースツリーには /usr/src/external/bsd/nsd にあるので make install すれ使えるようになります。バイナリが含まれていないのは権威サーバが必要な人は make くらいできるでしょ、という感じでしょうか。
ちなみに NetBSD-8 の nsd は 4.1.14(2016/12)、unbound は 1.6.8(2018/1) です。新しいバージョンは pkgsrc/net にありますので、必要な人は各自インストールでしょう。

php-fpmの動作確認。

Apache 2.4 の構成をいろいろといじっています。

Apacheのmod_cgiとmod_cgidとpreforkとevent。でも触れていますが、PHP と Perl と Python をそれぞれ別のアプリケーションで使いたいということなのですが、歴史的な経緯もあり、Perl は太古の CGI(ゆいちゃっと)、PHP は WordPress、Python は GNU Mailman 2 となります。それぞれの API は、ゆいちゃっとと Mailman が CGI で、WordPress が FastCGI を使おうと考えています。実際には CGI と FastCGI はアプリケーションから見ると同じなので、結局すべてを CGI または FastCGI でやる、という感じです。

NetBSD の pkgsrc では、www/fcgi に cgi-fcgi という実行形式が含まれていて、CGI 形式でリクエストを送ると、FastCGI として FastCGI デーモンに投げ、応答を再度 CGI 形式にして返してくれます。php-fpm で使ってみるとこんな感じ。
$SCRIPT_NAME=info.php SCRIPT_FILENAME=/srv/www/Test/info.php REQUEST_METHOD=GET cgi-fcgi -bind -connect /var/run/php_fpm.sock

Apache の mod_cgid は、ちょっと勘違いしていたんですが、Apache 2.4 の説明をよく読むと、
Unix オペレーティングシステムの中には、マルチスレッドのサーバから プロセスを fork するのが非常にコストの高い動作になっているものがあります。 理由は、新しいプロセスが親プロセスのスレッドすべてを複製するからです。 各 CGI 起動時にこのコストがかかるのを防ぐために、mod_cgid は子プロセスを fork して CGI スクリプトを実行するための 外部デーモンを実行します。 主サーバは unix ドメインソケットを使ってこのデーモンと通信します。
となっていて、mod_cgid 自体が子プロセスを fork して外部デーモンを起動する、ということは、別途外部デーモンを用意する必要はなく、そのあたりは mod_cgid で面倒を見てくれる、ということのようです。prefork で使われる mod_cgi は自分自身で面倒を見るけれど、worker/event で使われる mod_cgid は自分でデーモンを起動してそちらに任せる、ということで、アプリケーションから見ると何も変わらないことになります。

ということであれば、上記の Perl / PHP / Python のアプリケーションは全部 mod_cgid で引き受けることができそうです。外部に CGI サーバを別途用意するなら uWSGI の CGI plugin を使って、とか考えていましたが、特に必要はなさそうです。

一方、php-fpm などの FastCGI サーバが動かせるタイプのものは mod_proxy_fcgi を使ってやれば、Apache からプロセスを切り離すことができます。

ところで PHP 7.3.4 で preg_match() あたりで JIT 警告(正確には、"Warning: preg_match(): JIT compilation failed: no more memory in xxx")が出てるんですが、5月2日にリリースされた 7.3.5 では修正されているようですね。

TeXLive 2019 のインストール。

やっとミラーサーバにも TeXLive 2019 が回ってきたようで、ようやくインストールできるようになりました。
が、GUI のインストーラが立ち上がってもエラーで先に進みません。うちだけかもしれませんが。

インストーラを起動して、"unpack only" をしてから、そのディレクトリに移動して
%USERPROFILE%\install-tl-20190502\install-tl-windows.bat -no-gui でテキストモードでインストールするとちゃんとインストールできるみたいです。

ユーザローカルにインストールしたければ通常モードで、システムワイド(今までどおり c:\texlive)にインストールしたければ管理者モードでコマンドプロンプトを起動すればいいです。

bozohttpd。

NetBSD で Apache のオプションでモジュール一覧をするのがあったよな、と思い、詳細を確認しようとして man page を見ようとしたら、man apache はなくて、man httpd したらオプションの説明が期待したものと違っていて、ふとタイトルを見ると "BOZOHTTPD(8)" となっていました。なにそれと思ったら、
bozohttpd ? hyper text transfer protocol version 1.1 daemon
ということで、なんと NetBSD に標準で組み込まれている http daemon のようです。
今まで知らなかったのは最初から Apache を使ってたからでしょうけど、調べてみると 1999年5月19日に加えられたようです。歴史的には NetBSD-1.4 なので、たしか自分が NetBSD に手を出したのは Sparc のピザボックスでそのときは 1.3 だった気がするので、もうほとんど最初からそこにあったのに気づかなかったのですね。

pkgsrc の DESCR を見ると、
bozohttpd is a small and secure HTTP version 1.1 server. Its main
feature is the lack of features, reducing the code size and improving
verifiability.

It supports CGI/1.1, HTTP/1.1, HTTP/1.0, HTTP/0.9, ~user translations,
virtual hosting support, as well as multiple IP-based servers on a
single machine. It is capable of servicing pages via the IPv6 protocol.
It has SSL support. It has no configuration file by design.
とあって、CGI も IPv6 も SSL も仮想ホストもサポートしているようです。IPv6 については2000年に itojun 氏が追加しているようです。

ドキュメントはあまりないようで、pkgsrc のほうを見ても man page しかないようです。

結局Terminatorに戻った件。

ターミナルエミュレータを物色する。でいろいろと物色してみたんですが、結局また Terminator に戻ってきてしまいました。まあそれはいいんですが。

なので Terminator のキーバインドを自分用にメモ。というのも、設定から "PuTTY style paste"(右クリックでペースト)を指定したら、それまで右クリックで出ていた分割とか設定とかのコンテキストメニューが出なくなってしまったから。当然ですが。

まず設定メニューを出すにはマウスの右クリックですが、キーバインディングではできなさそうです。"PuTTY style paste" をチェックすると、マウスの中央ボタンがコンテキストメニュー起動になります。中央ボタンが効かない場合には、$HOME/.config/terminator/config ファイルを直接編集して無効にすればよいです。
それからSuperキーというのが出てきますが、いわゆる "Win" キーのことです。

キー 動作 キー 動作
F1 HTMLヘルプ C+S+カーソル ドラッグバーの移動
C+S+O 水平に分割 C+S+PageDown タブ位置を次のタブと入れ替え
C+S+E 垂直に分割 C+S+PageUp タブ位置を前のタブと入れ替え
C+S+T 新規タブ C+S+C 選択部分をコピー
C+S+I 新規Window C+S+V 貼り付け
Alt+LL レイアウトランチャー C+S+S スクロールバー表示のトグル
C+S+W 現在のターミナルを閉じる C+S+F 前方向検索
C+S+Q 現在のウィンドウを閉じる C+S+R ターミナルリセット
A+カーソル ターミナル間の移動 C+'+' フォントサイズ拡大
C+PageDown 次のタブに移動 C+'-' フォントサイズ縮小
C+PageUp 前のタブに移動 C+0 フォントサイズリセット
C+Tab/C+S+N 同一タブの次のターミナルに移動 C+A+W ウィンドウタイトル変更
C+S+Tab/C+S+P 同一タブの前のターミナルに移動 C+A+X ターミナルタイトル変更
Super+I 新規のTerminatorプロセス起動 F11 フルスクリーン切り替え

Chromiumでkeyringの入力を求められる件。その3

Chromiumでkeyringの入力を求められる件。で、もっと簡単な方法がありました。

Manjaro Linux Xfce4 版のみかもしれませんが、メニューから「設定」→「セッションと起動」に進みます。
そこで「SSH鍵エージェント(GNOMEキーリング:SSHエージェント)」と「シークレットストレージサービス」、「証明書および鍵を格納するストレージ」の3つにチェックを入れます。
これでログイン時に自動的に GNOME キーリングを起動してくれます。

ただし自動ログインではやっぱりダメなようです。

ターミナルエミュレータを物色する。

Manjaro をいじっていると、ターミナルエミュレータがデフォルトのものではちょっと不便さを感じてしまうので、物色してみました。

pacman -Ss terminalするとずらーっと出てきますが、そこからピックアップ。条件としては、せっかく軽い Xfce4 を使っているのだから軽いもの、かつタイル分割できるもの。なので Gnome とか KDE 系のものは一旦パス。
  • community/alacritty 0.2.9-1
    A cross-platform, GPU-accelerated terminal emulator
    依存パッケージ: freetype2 fontconfig xclip libxi libxcursor
  • community/jupyter_console 6.0.0-1
    An IPython-like terminal frontend for Jupyter kernels in any language.
    依存パッケージ: ipython python-jupyter_client python-ipykernel python-pygments python-prompt_toolkit
  • community/kitty 0.13.3-1
    A modern, hackable, featureful, OpenGL based terminal emulator
    依存パッケージ: python3 freetype2 fontconfig wayland libx11 libxkbcommon-x11 hicolor-icon-theme libgl
  • community/nyancat 1.5.2-1
    Nyancat rendered in your terminal.
    依存パッケージ: glibc
  • community/qterminal 0.14.1-1 (lxqt)
    A lightweight Qt-based terminal emulator
    依存パッケージ: hicolor-icon-theme qtermwidget qt5-x11extras
  • community/rxvt-unicode 9.22-7
    Unicode enabled rxvt-clone terminal emulator (urxvt)
    依存パッケージ: rxvt-unicode-terminfo libxft perl startup-notification libnsl
  • community/sakura 3.6.0-2
    A terminal emulator based on GTK and VTE
    依存パッケージ: vte3 libxft
  • community/terminator 1.91-6
    Terminal emulator that supports tabs and grids
    依存パッケージ: gsettings-desktop-schemas libkeybinder3 libnotify python2-cairo python2-dbus python2-psutil python2-gobject vte3 xdg-utils
  • community/sl 5.02-5
    Steam Locomotive runs across your terminal when you type "sl" as you meant to type "ls".
    依存パッケージ: ncurses
  • community/termite 14-2
    A simple VTE-based terminal
    依存パッケージ: gtk3 pcre2 gnutls vte-common termite-terminfo
  • community/tilix 1.9.0-1
    A tiling terminal emulator for Linux using GTK+ 3
    依存パッケージ: libx11 gtkd vte3 dconf gsettings-desktop-schemas
おかしなのも紛れ込んでいますがこんなものでしょうか。コアというか、ターミナルエミュレータ本体の部分は vte を組み込んでいるのが多いようです。

以前は Terminator を使っていたのですが、ちょっと重たい感じです。なので軽いものがいいな、と。
OpenGL を使って高速化しているのが alacritty と kitty。軽そうなのが termite とか sakura あたりでしょうか。"best terminal emulator linux" で検索するといくつかランキングページがでてくるのでそれも参考にしつつ。ちなみに termite というのはシロアリのことだそうです。

Sakura を使ってみたら、タイル型ではなくタブ型でした。なぜタイリングにこだわるかというと、サーバのログを "tail -f" で表示させながらエラー確認をすることが多いからです。

Termite は画面もシンプルで軽く、またモーダルというのがおもしろいです。ArchLinux に説明のページがあります。が、tiling という言葉があったので誤解したのですが、どうやらこれは「タイリング型のウィンドウマネージャ」ということらしいです。ちょっと使った感じとしては軽くていいのですが…。

Alacritty は GPU を使うということで、どのくらい使用するのかはわかりませんがスクロールなどは素早い印象です。

Kitty はタイリングというよりはマルチウィンドウみたいな感じで、ちょっと好みと違うかな。

とりあえず Alacritty がスタイル的に合いそうな気がするので、ちょっと使ってみたのですが、タイリングの部分は tmux を利用するようで、これはちょっとないかな。Alacritty は Windows 版もあるようですが、何が走るんだろう。設定などは Alacritty Wiki にあります。

結局また Terminator に戻りそうです。

それからターミナルエミュレータで256色を表示してみたいときには、show-all-256-colors.pyなんかを使うと手軽に表示できます。

Chromiumでkeyringの入力を求められる件。その2

Chromiumでkeyringの入力を求められる件。がその2に続いてしまいました。

su をすると /etc/profile.d/keryring.sh がエラーを出してきます。
% su
パスワード:
** Message: 08:21:18.322: couldn't access control socket: /run/user/1000/keyring/control: 許可がありません
** Message: 08:21:18.326: couldn't connect to dbus session bus: Could not connect: 許可がありません
** Message: 08:21:18.326: The gnome-keyring control directory cannot be accessed: /run/user/1000/keyring: 許可がありません

** (gnome-keyring-daemon:23044): WARNING **: 08:21:18.326: couldn't create socket directory: /run/user/1000/keyring-UERQ0Z: 許可がありません

** (gnome-keyring-daemon:23044): WARNING **: 08:21:18.326: couldn't bind to control socket: /run/user/1000/keyring-UERQ0Z/control: 許可がありません

これは無視しておけばいいんですが、ちょっとかっこ悪い。なのでなんとか対策を考えます。

su して superuser になると、UID が 0 になります。なのでこれを使ってみます。

/etc/profile.d/keyring.sh:
if [ $UID -ne 0 ]; then
  eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
  export SSH_AUTH_SOCK
fi

これでいいかどうか、ですが、基本的に root ログインはしないこと、root ログインするようなときはコンソールからになるだろうし、そこでウェブブラウザを使うような危険なことはしないことなどを考えると、いいんじゃないでしょうか。

Chromiumでkeyringの入力を求められる件。

Manjaro Linux で Chromium を立ち上げたときに、keyring が開けないといってパスワードを毎回求められるのが鬱陶しいです。Firefox とかでは出ないのに。
で、空のパスワードを設定するといいよ、という対策が引っかかってくるんですが…。Manjaro だと別のパッケージを新たにインストールすることになりますが、それはなんだか嫌です。それに空のパスワードを設定するのも気持ち悪いです。

追記: Chromiumでkeyringの入力を求められる件。その3でもっと簡単な方法を書きました。

Chromium keyring change?に方法が書かれていましたので、翻訳しておきます。

もし keyring パスワードにログインパスワードと同じものを設定しているなら 4 に飛んでください。
  1. ~/.local/share/keyrings内のファイルを削除します。
  2. Chromium を開きます。
  3. パスワード作成のダイアログが出てきたら、ユーザアカウントのパスワードと同じものを設定します。
  4. 以下の内容を /etc/pam.d/login の最後に追加します。
    auth       optional     pam_gnome_keyring.so
    session    optional     pam_gnome_keyring.so        auto_start
  5. 以下の内容を /etc/pam.d/passwd の最後に追加します。
    password    optional    pam_gnome_keyring.so
  6. 以下の内容で /etc/profile.d/keyring.sh を作成します。
    eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
    export SSH_AUTH_SOCK
  7. 一旦ログアウトして再度ログインします。
ホームディレクトリのドットファイルを整理する。でも書いていますが、/etc/profile.d/*.shはログイン時に読み込まれ、実行されるようになっていますので、上記の keyring.sh は自動で実行されます。

ログインパスワードを変更した場合には上記の動作は無効になりますので、再度1から3をやり直すか、seahorseを使って新しいパスワードを設定する必要があります。
また、この方法は PC の起動時に自動ログインの設定がしてあると、うまく行きません。

だそうです。

ホームディレクトリのドットファイルを整理する。

UNIX 系の OS で、ちょっと悩ましいのは $HOME(ホームディレクトリ)にドットファイルが増えてしまうことです。

ls -a すると表示されるリストの8割以上がドットファイルとか、もう許して下さいな感じです。

% ls -a
.              .aliases~                        .dbus        .hgignore   .profile         .xinitrc              .zshrc~    __pycache__
..             .bash_history                    .dir_colors  .hgignore~  .python_history  .xprofile             Desktop    bin
.ICEauthority  .bash_logout                     .dmrc        .hgrc       .ssh             .xsession-errors      Documents  build
.Xauthority    .bash_profile                    .esd_auth    .hgrc~      .texlive         .xsession-errors.old  Downloads  work
.Xclients      .bashrc                          .gem         .lesshst    .thumbnails      .zcompdump            Music
.Xmodmap       .cache                           .gkrellm2    .local      .thunderbird     .zsh                  Pictures
.Xmodmap.orig  .chrome-remote-desktop-session   .gnupg       .mozc       .vim             .zshenv               Public
.Xmodmap~      .chrome-remote-desktop-session~  .gvimrc      .mozilla    .vimrc           .zshenv~              Templates
.aliases       .config                          .hg          .pki        .wget-hsts       .zshrc                Videos

編集した結果バックアップファイルやらコピーを残してるのやらありますが、まあざっとこんな感じ。もうちょっと整理して数を減らしたいところです。
このときに頼りになるのが XDG Base Directory Specification。それを規格から実装に照らして説明してくれているのがこちら

なので一つ一つやっていきます。環境は Manjaro Linux XFCE 版なので、他のディストロは適当に読み替えてください。

システム

システム側であらかじめ設定されているのは以下の環境変数です。
XDG_SESSION_ID=c5
XDG_RUNTIME_DIR=/run/user/1000
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
また、ユーザ側で設定しておきたいのは以下の環境変数です。
XDG_CONFIG_HOME=$HOME/.config
XDG_CACHE_HOME=$HOME/.cache
XDG_DATA_HOME=$HOME/.local/share
XDG_RUNTIME_DIR はユーザごとに設定される /var/run みたいなものです。デフォルトではユーザIDが振られています。必要なら設定すればよいでしょう。
それとは別に、/etc/xdg に設定ファイルがいくつか置かれています。ただしこれらは ssh ログイン時などには読み込まれないようなので、ここでは置いておきます。
ここでは、お仕着せでシステムワイドに設定する方向で進めていきます。

bash

まずは標準の shell の bash。Manjaro の場合には、次の順序で読み込まれるようです。bash -l -v で確認しました。つまりログインシェルの場合。
  1. /etc/profile
  2. /etc/profile.d/*.sh
    /etc/profile から呼ばれる。アルファベット順に読み込まれる。アプリケーションごとに必要な設定はここ。ロケールもここ。
  3. /etc/bash.bashrc
    /etc/profile から呼ばれる。システムワイドの bash 設定を行う。プロンプトや $TERM の設定はここ。
  4. /usr/share/bash-completion/bash_completion
    もしあれば読み込まれる。Manjaro にはない。
  5. $HOME/.bash_profile
    $HOME/.bashrc を source しているだけ。
  6. $HOME/.bashrc
    ユーザの環境変数とか alias とかいろいろと設定する。
  7. プロンプトが表示されて bash 起動完了。
  8. $HOME/.bash_logout
    ログアウト時に読み込まれる。何もしていない。
  9. /etc/bash.bash_logout
    ログアウト時に読み込まれる。何もしていない。
bash の場合にはユーザごとのドットファイルはハードコードされているようなので、ドットファイル類を .config/bash に移動することは(現状では)できません。ただ、他のアプリケーションのための設定は必要なので、ここでは /etc/profile.d/xdgenv.sh あたりで XDG ユーザ変数を設定するようにすればよいでしょう。そうすることで他の shell からも source することができます。
/etc/profile.d/xdgenv.sh:
# Set user variables based on XDG Base Directory Specification.
#

export XDG_CONFIG_HOME=$HOME/.config
export XDG_CACHE_HOME=$HOME/.cache
export XDG_DATA_HOME=$HOME/.local/share

zsh

zsh では環境変数 ZDOTDIR が設定されているとそこを見に行きます。
  1. /etc/zsh/zshenv
    本来は /etc/zshenv を読みにいく(manページの説明)ようだが、Manjaro では /etc/zsh/zshenv を読みにいく。
  2. $ZDOTDIR/.zshenv
    環境変数 ZDOTDIR が指定されていれば $ZDOTDIR/.zshenv を、指定されていなければ $HOME/.zshenv を読む。
  3. /etc/zsh/zprofile
    Manjaro では /etc/zsh/zprofile の中身は emulate sh -c 'source /etc/profile' となっていて、/etc/profile を読み込む。/etc/profile の読み込むものは bash と同じ。
  4. $ZDOTDIR/.zprofile
    ZDOTDIR が指定されていなければ $HOME/.zprofile を読み込む。
  5. /etc/zsh/zshrc
  6. $ZDOTDIR/.zshrc
  7. /etc/zsh/zlogin
    ログインシェルの場合に読み込まれる。
  8. $ZDOTDIR/.zlogin
    ログインシェルの場合に読み込まれる。
  9. プロンプトが表示されて bash 起動完了。
  10. $ZDOTDIR/.zlogout
    ログアウト時に読み込まれる。何もしていない。
  11. /etc/zsh/zlogout
    ログアウト時に読み込まれる。何もしていない。
ということなので、bash のところで /etc/profile.d/xdgenv.sh を作成していれば、XDG* はそこで設定されます。また、/etc/zsh/zshenv があれば一番最初に読み込まれるので、ZDOTDIR をそこで設定すればいいのですが、ZDOTDIR=$XDG_CONFIG_HOME/zsh とする必要があるため、二重に読み込むことになりますが以下のようにします。
# /etc/zsh/zshenv
# set ZDOTDIR respecting XDG Base Directory Specification
#

emulate sh -c 'source /etc/profile'
export ZDOTDIR=$XDG_CONFIG_HOME/zsh
また、標準ではコマンドヒストリは $HOME/.zsh/histfile に保存されますが、これを $XDG_CACHE_HOME/zsh/history に変更します。コマンドヒストリはユーザ設定なので、これは $XDG_CONFIG_HOME/zsh/.zshrc で設定し直します。
$XDG_CONFIG_HOME/zsh/.zshrc:
HISTFILE=$XDG_CACHE_HOME/zsh/hisotry
zstyle :compinstall filename '$ZDOTDIR/.zshrc'
これで $HOME から zsh 関連のドットファイルは削除できます。

git

0d94427eから XDG_CONFIG_HOME に対応しているので、$XDG_CONFIG_HOME/git/config を使います。

Neovim

Neovim は最初から XDG Base Directory Specification に沿うように作られているので、$XDG_CONFIG_HOME/nvim を利用すれば問題ありません。
ここで、vim からも同じ設定を使えるように init.vim などを記述しておくと、nvim でも vim でも同じように使えます。

vim

vimはちょっとややこしいです。前述の ArchLinux の Wiki に書いてあるように、.vimrc などは基本的にハードコードされています。が、別途 VIMINIT=":source $XDG_CONFIG_HOME"/vim/vimrcを shell の設定時に行っておけば、vim の起動時に $VIMINIT を参照してくれます。
なので $ZDOTDIR/.zshenv に設定しておきます。ここでは vim と nvim の設定を共通にすることを考えているので、あえて $XDG_CONFIG_HOME/nvim/vimrc にします。ただし、undodir などが一緒になると問題があるかもしれないので、そこは別にしておきます。Manjaro の場合には vim は標準ではインストールされていなくて、ex および vi が標準なので、あえて vim をインストールせずに alias vim=nvim するのもアリかもしれません。
# .zshenv

PATH1=$HOME/bin
export PATH=$PATH:$PATH1

export QT_SELECT=5
export GTK_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export QT_IM_MODULE=fcitx

# better yaourt colors
export YAOURT_COLORS="nb=1:pkg=1:ver=1;32:lver=1;45:installed=1;42:grp=1;34:od=1;41;
5:votes=1;44:dsc=0:other=1;35"

# env for locate updatedb for local files.
export PRUNEPATHS="`echo $HOME/.cache/[a-ce-z]*`"
export PRUNEPATHS="`find $HOME -name \".hg\" -printf \"%p \"` $PRUNEPATHS"
export PRUNEPATHS="$HOME/.mozilla $HOME/.dbus $HOME/.thumbnails $HOME/.thunderbird $
PRUNEPATHS"
export LOCATE_PATH=$XDG_CACHE_HOME/mlocate.db

export VIMINIT=":source $XDG_CONFIG_HOME"/nvim/vimrc
また、vimrc は以下の内容にします。
" vim:set et ts=2 sts=2 sw=2 tw=0 fenc=utf-8:
" _vimrc : initialization file for Vim.
" just source init.vim for commonnization.
"
" Modified: 9 Apr 2018
"
source $XDG_CONFIG_HOME/nvim/init.vim

" mswin.vim maps those keys when gui=yes.
" this is terrible and should be unmapped.
if has('gui')
  unmap <C-f>
  iunmap <C-f>
  cunmap <C-f>

  unmap <C-h>
  iunmap <C-h>
  cunmap <C-h>
endif

mercurial

$HOME/.hgrc は $XDG_CONFIG_HOME/hg/hgrc に移動することができます。が、.hgignore はそのディレクトリ以下の ignore ファイルを指定しているため、移動できません。また .hg ディレクトリはリポジトリのため、移動できません。

その他

.ICEauthority

libice が作成するファイルですが、Use XDG base directory instead of $HOME for .ICEauthorityで議論され、パッチがあげられ、2019年3月25日に push されているので、いずれマージされるでしょう。
それまでは触らないでおくか、export ICEAUTHORITY="$XDG_RUNTIME_DIR"/ICEauthority を /etc/zsh/zshenv あたりに入れておけばよいでしょう。ただ、環境変数がやたら増えるのも困りものですから、ここでは放置しておきます。

.Xauthority

同上です。export XAUTHORITY="$XDG_RUNTIME_DIR"/Xauthority

.Xmodmap

対応策はなさそうです。

.dircolors

source "$(dircolors "$XDG_CONFIG_HOME"/dircolors)" を $ZDOTDIR/.zshenv あたりに入れておきます。bash のほうは $HOME/.bashrc のdircolors に関する部分の変更が必要です。

.mozc

移動できません。ソースを見ましたが、XDG_CONFIG_HOME を参照している部分はありませんでした。

.mozilla(firefox)

$XDG_CONFIG_HOME/mozilla と $XDG_CACHE_HOME/mozilla と $XDG_DATA_HOME/mozilla がある場合にはそちらを使うようです。
なので、以下のようにします。
$ mkdir .config/mozilla
$ mkdir .cache/mozilla
$ mkdir .local/share/mozilla
$ chmod 700 .config/mozilla .cache/mozilla .local/share/mozilla

.python_history

Python がインタラクティブモードで起動されると readlline が作成するようです。今のところ移動できません。

.texlive

ハードコードされているようで変更できません。

.thumbnails

$XDG_CACHE_HOME/thumbnails/ があればそちらを使うようです。

.thunderbird

ハードコードされているようで変更できません。

.xinitrc

基本的には DesktopManager(lightdmやgdmなど)を使っていれば xinit を呼ぶことはないので不要なはずですが、export XINITRC="$XDG_CONFIG_HOME"/X11/xinitrc を指定することで xinit は参照してくれます。

.gnupg

export GNUPGHOME="$XDG_CONFIG_HOME"/gnupgすることで参照してくれます。

Jcode.pmではなくてEncode.pmを使う。

自分のPerlに関する情報は10年以上前から止まってた、ということですね。
Jcode.pm - jcode.pl の後継、Encode.pm への架け橋というページで、2008年5月に
Perl 5.8.0 より、Jcodeの全機能は Encode module を通じてPerlに標準装備となります。Jcodeのメンテナンスは旧Perlのために 今後も続けていく所存ですが、最新のPerlをお使いの方には、より高機能、高 性能、そしてなんといっても標準装備の Encode の方をお薦めします。
ということだそうで、現在の環境では Jcode.pm ではなくて Encode.pm(Encode::JP) を使うのがよい、と。Encode.pm は core に取り込まれてるんですね。

未だにサーバには jcode.pl を使った古典的CGIアプリが走っているので、最近のサーバのトレンドに合わせて FastCGI と SQLite を使うように書き直して、あるいはもしかしたら PHP とか Python あたりで書き直したほうがいいのかも。

MercurialとPython3。その2

MercurialとPython3。のところではその時点でのステータスを拾ってきていたんですが、どうやら編集されているようです。
1. Status
Mercurial 5.0 is the first release that officially has beta support for Python 3. Supported Python 3 versions are 3.5, 3.6, and 3.7. Python 3.8 mostly works, but there are a few known incompatibilities. Mercurial with Python 3 on Windows is not yet widely tested and there are more known issues on Windows compared to Linux, macOS, and other UNIX-like platforms.

It is the project policy for Mercurial and its core extensions to be compatible with Python 3. Over 99% of tests pass with Python 3 and test regressions are treated seriously.

Many 3rd party extensions have not yet been ported to work with Python 3.

Mercurial 5.0 は公式に Python 3 をベータサポートする最初のリリースです。サポートされる Python 3 のバージョンは 3.5、3.6 および 3.7 です。Python 3.8 はほとんど動きますが、いくつかの既知の適合性の不一致があります。Windows での Python 3 の Mercurial はまだ十分にテストされておらず、Linux、macOS およびタの UNIXライクなプラットフォームに比べて多くの既知の問題があります。

Mercurial とそのコアエクステンションが Python 3 と適合していることはプロジェクトのポリシーです。Python 3 では 99% を超えるテストをパスし、回帰テストは慎重に行われています。

多くのサードパーティエクステンションはまだ Python 3 で動くようにポーティングされてはいません。

らしいです。
前のエントリでは 5月1日リリースという目標だったようですが、さて。

Apacheのmod_cgiとmod_cgidとpreforkとevent。

自分用メモ。

  • mod_cgi
    Unix でマルチスレッドの MPM を使っている場合は、このモジュールの 代わりに mod_cgid を使う必要があります。 ユーザレベルではこの二つのモジュールは本質的には同一です。
  • mod_cgid
    Unix オペレーティングシステムの中には、マルチスレッドのサーバから プロセスを fork するのが非常にコストの高い動作になっているものがあります。 理由は、新しいプロセスが親プロセスのスレッドすべてを複製するからです。 各 CGI 起動時にこのコストがかかるのを防ぐために、mod_cgid は子プロセスを fork して CGI スクリプトを実行するための 外部デーモンを実行します。 主サーバは unix ドメインソケットを使ってこのデーモンと通信します。

    コンパイル時にマルチスレッド MPM が選ばれたときは mod_cgi の代わりに必ずこのモジュールが使用されます。 ユーザのレベルではこのモジュールの設定と動作は mod_cgi とまったく同じです。唯一の例外は ScriptSock ディレクティブの 追加で、このディレクティブは CGI デーモンとの通信用のソケットの名前を 指定します。
  • prefork
    このマルチプロセッシングモジュール (MPM) は、 Unix 上での Apache 1.3 のデフォルトの挙動と非常によく似た方法で リクエストを処理する、スレッドを使わず、先行して fork を行なう ウェブサーバを実装しています。 スレッドセーフでないライブラリとの互換性をとるために、 スレッドを避ける必要のあるサイトでは、このモジュールの使用が適切でしょう。 あるリクエストで発生した問題が他のリクエストに影響しないように、 個々のリクエストを単離するのにも、最適な MPM です。
  • event
    The event Multi-Processing Module (MPM) is designed to allow more requests to be served simultaneously by passing off some processing work to the listeners threads, freeing up the worker threads to serve new requests.

    event is based on the worker MPM, which implements a hybrid multi-process multi-threaded server. A single control process (the parent) is responsible for launching child processes. Each child process creates a fixed number of server threads as specified in the ThreadsPerChild directive, as well as a listener thread which listens for connections and passes them to a worker thread for processing when they arrive.

    event マルチプロセッシングモジュール(MPM)は、処理動作のいくつかをリスナースレッドに受け渡し、新しいリクエストを扱うためにワーカースレッドを開放することによって、より多くのリクエストを同時に受け入れるように設計されている。
    event は、マルチプロセスとマルチスレッドのハイブリッドサーバである worker MPM をベースとしている。一つのコントロールプロセス(親)が子プロセスの起動を行う。それぞれの子プロセスは ThreadPerChild ディレクティブで指定された固定数のサーバスレッドを、接続を待ち受けてそれを処理するためにワーカースレッドに受け渡す一つのリスナースレッドと同時に生成する。
  • worker
    このマルチプロセッシングモジュール (MPM) は、マルチスレッドとマルチプロセスのハイブリッド型サーバを 実装しています。リクエストの応答にスレッドを使うと、 プロセスベースのサーバよりも少ないシステム資源で、 多くのリクエストに応答することができます。 それにもかかわらず、多くのスレッドを持った複数のプロセスを 維持することで、 プロセスベースのサーバの持つ安定性も保持しています。
というようなことをまとめてみると、prefork はマルチプロセス、event と worker はマルチプロセス/マルチスレッドということになります。スレッドセーフじゃない CGI は prefork のほうがいい、でも prefork はリソースを食うから、スケーラビリティが重要ならスレッドセーフにして event か worker を使う、という感じでしょうか。
一方でこういう記事を見つけました。
ApacheでCGIを使う場合にpreforkを使った方が良い状況とそのチューニングについて。ここでは mod_cgid がシングルプロセスであるため、そこがボトルネックになってリクエストを取りこぼす状況がありうるということが示唆されています。一方 mod_cgi はリクエストごとに個別にプロセスを起動するため、マルチスレッドではないがマルチプロセスが有効に働いてかなりいい数値を出してきています。もちろんこれは PC のコア数、アプリケーションの処理内容とか DB へのアクセスなどの複合要因で変わってくるとは思いますが、シナリオによっては prefork のほうがよい場合がある、ということを示唆しています。

(以下の表は作成中に付き嘘がいっぱいかもしれない)

MPM 実装 CGI FastCGI Perl Python PHP
prefork マルチプロセス mod_cgi mod_fcgi mod_cgi
mod_fcgi
mod_proxy_uwsgi mod_php
worker マルチプロセス
マルチスレッド
mod_cgid mod_proxy_uwsgi php_fpm
event マルチプロセス
マルチスレッド
mod_cgid mod_proxy_fcgi mod_proxy_uwsgi php_fpm
ちょっと分かりづらいので、もうちょっと分類してみようと思います。
  • mod_cgi
    prefork の場合には mod_cgi が使われる。
  • mod_cgid
    event および worker の場合には mod_cgid が使われる。ScriptSock ディレクティブが追加されていて、UNIX ソケットを扱える。
  • mod_mime
    AddHandlerは mod_mime がサポートしている。
  • mod_alias
    ScriptAliasは mod_alias がサポートしている。
  • mod_proxy
    Apache は他の CG Iへのインタフェースのために PROXY モジュールを利用する。ProxyPassは mod_proxy がサポートしている。
  • mod_proxy_fcgi
  • mod_proxy_scgi
  • mod_proxy_uwsgi
  • uWSGI Perl support (PSGI)
    PSGI とカッコ書きで書いてあるとおり、PSGI へのインタフェースを提供するもの。つまり Plack のようなミドルウェアが必要となるし、PSGI daemon(もしくはサーバ)が必要となる。
  • Running PHP scripts in uWSGI
  • Running CGI scripts on uWSGI
    これは CGI 実行のためのサーバなどを必要としないので、イメージとしては uWSGI が CGI プログラムを実行してそれを ポートあるいはソケット経由で Apache や Nginx に提供する形になる。mod_cgi を mod_cgid + uWSGI with CGI plugin で置き換える感じ。
  • PSGI/Plack
  • Perl CGI
  • mod_http2
    MPM Configurationによれば、prefork では mod_http2 はたった一つのコネクションしか扱えないためにサーバがストールするため、ベストな選択は event を使うこと。
  • ProxyPass ディレクティブ
  • mod_wsgi
  • mod_fcgid
    リポジトリを見ると、2.3.9(最新版)がリリースされたのは2013年10月。Apache 2.5 のドキュメントは用意されているようだが、メンテナンスされているのかどうかは不明。fcgi + mod_proxy_fcgid のほうがよいかも。

こうしてピックアップしてみると、Webアプリケーションをサーバで動かすにはいろいろと方法があって、どれが最適化はそのアプリケーション(あるいは言語やプラットフォーム)によるし、唯一無二のベストなソリューションはない、というか、ないからこそいろいろな方法があるんでしょうね。

CGI でふと思い出したけれど、Wikiエンジンで一番最初に触れた TWiki は Perl で動かしていたのでした。

Perl 関連:
(作成中)
CGI::Alternativesによれば、
(他の言語でもそうだけれど)コード中に html コードを組み込むのではなく、Perl コードと HTML コードを分離してテンプレート化して利用するほうがよい。CGI.pm は 5.22 以降ではすでに core から外されて、標準ライブラリではなくなっている。コードとHTMLを切り離すテンプレート方式を強く推奨するし、新規で開発するなら MojoliciosDancer2CatalystあるいはPSGI/Plackを使うべき。常に使われるような軽めのアプリケーションなら Mojolicios か Dancer2 を、大きいアプリケーションなら Catalyst を検討したほうがよい。
という感じ。
Plack/PSGI のインストールは Handbook を参考に。
太古のCGIプログラム
CGIプログラム
CGI::Fastプログラム
Plackプログラム

(余談)
Manjaro では Plack のパッケージがなかったため、CPAN からインストールしたらぞろぞろとたくさんのパッケージがインストールされた。
Apache-LogFormat-Compiler-0.35-0  File-ShareDir-1.116-0         LWP-MediaTypes-6.04-0           Test-LeakTrace-0.16-0
Class-Inspector-1.34-0            File-ShareDir-Install-0.13-0  List-MoreUtils-0.428-0          Test-MockTime-0.17-0
Cookie-Baker-0.10-0               Filesys-Notify-Simple-0.13-0  List-MoreUtils-XS-0.428-0       Test-Requires-0.10-0
Cpanel-JSON-XS-4.11-0             HTTP-Date-6.02-0              Module-Build-0.4229-0           Test-SharedFork-0.35-0
Devel-StackTrace-2.03-0           HTTP-Entity-Parser-0.21-0     Module-Build-Tiny-0.039-0       Test-TCP-2.19-0
Devel-StackTrace-AsHTML-0.15-0    HTTP-Headers-Fast-0.22-0      POSIX-strftime-Compiler-0.42-0  Test-Time-0.07-0
Encode-Locale-1.05-0              HTTP-Message-6.18-0           Params-Util-1.07-0              Test-Warnings-0.026-0
Exporter-Tiny-1.002001-0          HTTP-MultiPartParser-0.02-0   Plack-1.0047-0                  Try-Tiny-0.30-0
ExtUtils-Config-0.008-0           Hash-MultiValue-0.16-0        Stream-Buffered-0.03-0          WWW-Form-UrlEncoded-0.25-0
ExtUtils-Helpers-0.026-0          IO-HTML-1.001-0               Test-Deep-1.128-0
ExtUtils-InstallPaths-0.012-0     JSON-MaybeXS-1.004000-0       Test-Fatal-0.014-0

Apache で FastCGI アプリケーションを動作させる方法は現実的には二通りで、mod_fcgid を使って Apache にサーブさせる方法と、mod_proxy_fcgi を使って他の FastCGI サーバへの proxy をさせる方法がありますが、mod_fcgid はApache のパッケージには含まれていないため今後どうなるかが不明なのと mod_fcgid 自体がパフォーマンスを優先するためかリソースをどか食いするらしいこと、どうやら時代の流れ的には uWSGI にしても PSGI にしてもそうですがアプリケーションの管理は外部のサーバに任せて、Apache 自体は PROXY を通して利用する、という方向なのかなという感じ。Perl の場合には Plack を使うか、fcgiwrap + spawn-fcgi でサーブさせるか、の二通りがありそうです。
spawn-fcgi は lighttpd に含まれているようです。


Python 関連:
(作成中)
uWSGI
GNU Mailmanは、Mailman 2.1 は Python 2.7 でかつ CGI/1.1 API が必要、Mailman 3 は Python 3.4 以降で WSGI が必要、ということなので、もしかして Django ベースのアプリを使わないなら CGI あるいは FastCGI で十分に足りてしまいそうな予感。というかそれがベストかもしれません。

PHP 関連:
(作成中)
PHP で使うアプリは今のところ WordPress のみなので、php-fpm を使って FastCGI で構築すればよさそうです。

ということは、Perl も含めて、Apache の FastCGI(mod_proxy_fcgi) で全部扱えそうな感じです。

pacmanについて。

Manjaro Linux とか Arch Linux とか MSYS2 とかは、パッケージ管理に pacman を使用しています。pacman はもともとが Arch Linux のパッケージ管理のために開発されており、Arch Linux をベースとした Manjaro Linux や FreeBSD をベースとした PacBSD で採用されています。
その他のパッケージマネージャとしては RedHat Linux が開発した rpm(とそれをベースとした yum)、Debian Linux が開発した dpkg(とそれをベースとした aptなど)、NetBSD が開発した pkgsrc システムなどがあります。

で、ここでは最近 NetBSD と並行して使い始めた Manjaro Linux で採用している pacman について、簡単にまとめておきます。つまり自分用メモ。

動作 指定オプション 説明
インストール -S [パッケージ名] ひとつ、あるいは複数のパッケージをインストールする。
依存パッケージがあればそれもインストールされる。
パッケージ名の代わりにグループ名も指定できる。
インストール -Sg [グループ名] グループ名で指定されたグループに含まれるパッケージ名を表示する。
削除 -R [パッケージ名] 特定のパッケージのみ削除する。
削除 -Rs [パッケージ名] 特定のパッケージと、そのパッケージのみが依存しているパッケージを削除する。
アップグレード -Syu リポジトリデータベースと同期して、アップグレードがあるシステム内のパッケージをすべてアップグレードする。
部分的なアップグレードはサポートされていない。
検索 -Ss [検索ワード] 指定された検索ワードにマッチするものがリポジトリにあれば表示する。
検索 -Qs [検索ワード] インストール済みのパッケージから検索する。
検索 -Si [パッケージ名] パッケージに関する詳しい情報を表示する。
検索 -Qi [パッケージ名] インストール済みのパッケージに関する詳しい情報を表示する。
検索 -Ql [パッケージ名] パッケージによってインストールされたファイルの一覧を表示する。
検索 -Qo [/パス/ファイル名] どのパッケージがそのファイルをインストールしたかを表示する。
検索 -Qdt 依存関係のない孤立したパッケージの一覧を表示する。
キャッシュの削除 -Sc ダウンロードしたパッケージファイルをキャッシュから削除する。
警告が出た -Syuu ローカルの[パッケージ]のほうが最新です というメッセージが出たときに

あるパッケージを導入して、そのパッケージが依存するパッケージもいくつかインストールされたけど、不要になって依存関係ごと削除したくなったら "-Rs" を使えばいいわけですね。

pacman -Sh すると、"-S" 関連のオプションフラグ一覧を表示してくれます。

オプション 意味
-y サーバーから最新のパッケージデータベースをダウンロード
-u インストールしたパッケージのアップグレード
-uu でダウングレードを有効
とかなっていて、"-Syuu" は必要があればダウングレードも行うってことでしょうか。pacman の man page を見ると、
-u, --sysupgrade
Upgrades all packages that are out-of-date. Each currently-installed package will be examined and upgraded if a newer package exists. A report of all packages to upgrade will be presented, and the operation will not proceed without user confirmation. Dependencies are automatically resolved at this level and will be installed/upgraded if necessary.

Pass this option twice to enable package downgrades; in this case, pacman will select sync packages whose versions do not match with the local versions. This can be useful when the user switches from a testing repository to a stable one.

Additional targets can also be specified manually, so that -Su foo will do a system upgrade and install/upgrade the "foo" package in the same operation.
現在異ストールされているそれぞれのパッケージについて検査し、新しいものがあればアップグレードする。必要があれば依存関係についても自動的に解決されてインストール/アップグレードが行われる。
このオプションを二重("-uu")に指定するとダウングレードを可能にする。この場合、pacman はローカルのバージョンと一致しないパッケージを選択する。これは "testing" リポジトリから "stable" リポジトリに切り替える場合などに重宝する。
また追加のターゲットを手動で指定することもでき、"-Su foo" はシステムアップグレードを行ってかつ "foo" パッケージをインストール/アップグレードも同時に行う。

"-Syuu" を指定すると、どうやらリポジトリの最新バージョン(stable?)に同期するようにローカルにある「リポジトリよりも新しいパッケージ」をダウングレードするようです。おそらくは何らかの理由(バグなど?)によってパッケージがリポジトリから削除された場合などに、ローカルのほうがその削除パッケージをインストールしてしまっていたときには、一つ前のバージョンなどにダウングレードする、というような動作でしょうか。

ManjaroLinuxでChrome Remote Desktopを有効にする。

以前には設定して使ってたのですが、Chromium 自体がなぜか CPU 時間をめちゃくちゃ食っていたので、Manjaro 上ではずっと Firefox を使っていました。

でもそろそろコンソールを KVM スイッチで切り替えながら使うのも煩わしくなってきたので、もう一度使ってみようということでインストールしてみました。

まず、Manjaro では chrome-remote-desktop は AUR にあります。なので、Pamac(パッケージマネージャ GUI)で、AUR を有効にします。
当然ながら AUR は公式ではないので、何かあっても基本的には自己責任です。

AUR を有効にしたら、左側の「アップデート」をしてリポジトリを読み込み、「検索」で "chrome-remote-desktop" を検索します。
インストールが終わったら、Chromium を起動してブックマークバーのアプリアイコンを起動し、「Chromeリモートデスクトップ」を選択して PIN コードを取得、Windows 側に戻ってその PIN コードで接続します。

ちなみに上のスクリーンショットは GIMP で行いました。GIMP のスクリーンショットは、ショットボタンを押してから取り込みたいウィンドウをクリックして表に出し、指定秒数後に再度クリックすることで取り込むことができます。

さて、これだけだと毎回 PIN を入力しないと接続できません。そこでセッションを定義して常に接続可能なようにしておくと、いつでも Windows から接続が可能になります。
Chrome リモート デスクトップを使って他のパソコンにアクセスするの Linux のところの「ステップ3」、AUR の Package Details: chrome-remote-desktop のコメント、および Stack Exchange の Configuring Chrome Remote Desktop with Ubuntu Gnome 14.04 を参考にします。
  1. まず、/usr/share/xsessions/ にある *.desktop というファイルを確認します。うちの Manjaro は XFCE4 を使っているので、xfce.desktop というファイルがあります。
  2. xfce.desktop の中身を確認すると、最後のところに
    Exec=startxfce4
    Icon=
    Type=Application
    DesktopNames=XFCE
    という部分があります。この Exec で実行されているのがセッションです。
  3. ホームディレクトリに、.chrome-remote-desktop-session というファイルを作成します。ファイルの内容は、
    exec /usr/bin/startxfce4
    です。
  4. /opt/google/chrome-remote-desktop/chrome-remote-desktop ファイルを編集します。念のためオリジナルは cp chrome-remote-desktop chrome-remote-desktop.original とでもして保存しておきます。
    % diff -rub chrome-remote-desktop.original chrome-remote-desktop
    --- chrome-remote-desktop.original      2019-04-19 18:30:39.726890222 +0900
    +++ chrome-remote-desktop       2019-04-19 18:30:59.576888872 +0900
    @@ -75,11 +75,12 @@
     # with large or multiple monitors. This is a comma-separated list of
     # resolutions that will be made available if the X server supports RANDR. These
     # defaults can be overridden in ~/.profile.
    -DEFAULT_SIZES = "1600x1200,3840x2560"
    +#DEFAULT_SIZES = "1600x1200,3840x2560"
    +DEFAULT_SIZES = "1920x1080"
    
     # If RANDR is not available, use a smaller default size. Only a single
     # resolution is supported in this case.
    -DEFAULT_SIZE_NO_RANDR = "1600x1200"
    +DEFAULT_SIZE_NO_RANDR = "1920x1080"
    
     SCRIPT_PATH = os.path.abspath(sys.argv[0])
     SCRIPT_DIR = os.path.dirname(SCRIPT_PATH)
    @@ -101,7 +102,7 @@
     SYSTEM_SESSION_FILE_PATH = "/etc/chrome-remote-desktop-session"
    
     X_LOCK_FILE_TEMPLATE = "/tmp/.X%d-lock"
    -FIRST_X_DISPLAY_NUMBER = 20
    +FIRST_X_DISPLAY_NUMBER = 0
    
     # Amount of time to wait between relaunching processes.
     SHORT_BACKOFF_TIME = 5
    @@ -720,8 +721,8 @@
         self._init_child_env()
         self._setup_pulseaudio()
         self._setup_gnubby()
    -    self._launch_x_server(x_args)
    -    self._launch_x_session()
    +    #self._launch_x_server(x_args)
    +    #self._launch_x_session()
         display = self.get_unused_display_number()
         self.child_env["DISPLAY"] = ":%d" % display
    
  5. /etc/pam.d/chrome-remote-desktop というファイルを作成し、以下の内容を追加します。うちの場合、これがないと認証ができなくて chrome-remote-desktop がすぐに終了してしまいます。
    auth        required    pam_unix.so
    account     required    pam_unix.so
    password    required    pam_unix.so
    session     required    pam_unix.so
    
    ちなみにその時のエラーメッセージはこんな感じでした。
    % crd --restart
    The daemon is not currently running
    [0419/174820.966447:INFO:remoting_user_session.cc(691)] Daemon process started in the background, logging to
    [0419/174820.968761:WARNING:remoting_user_session.cc(613)] Failed to read from message pipe. Please check log
    
    Log file: /tmp/chrome_remote_desktop_20190419_174820_pXzIoB
  6. 終わったらファイルを保存して、systemctl --user enable chrome-remote-desktop します。また、% crd --start (あるいは systemctl --user start chrome-remote-desktop)もしておきます。
  7. chrome から「アプリ」→「Chrome リモートデスクトップ」をクリックし、一番下に追加された「リモート接続を有効にする」をクリックして、PIN コードを設定します。
  8. 他のパソコンから Chrome リモートデスクトップでこのパソコンを選択して、設定した PIN コードを入力します。
以上で常時接続可能になります。

Docker関連の情報集め。

なんでクジラ?

Docker Desktop for Windows のアイコンはクジラですが、なんでクジラなんだろうと考えていました。
仮想マシンのイメージは C:\Users\Public\Documents\Hyper-V\Virtual hard disks にありますが、そのファイル名は MobyLinuxVM.vhdx です。VHD(Virtual Hard Disk)はもともと Windows XP 以降で一部のエディションに組み込まれていた Virtual PC が使用していた形式で、VHDX 形式はジャーナリングによって耐障害性をあげたり最大容量を増やしたりしたもののようです。

仮想マシンのファイル名が MobyLinuxVM ということで、クジラのアイコンは Moby 繋がりなんでしょうか。でも Moby-Dick は白いマッコウクジラですし、そこらへんどうなんでしょうか。ちなみにこのアイコンのモデルは "Moby Dock" という名前だそうです。CALL ME MOBY DOCK。Moby Dock が背中に載せているのはコンテナなので、Docker の構造を表しているようですね。

余談ですが、mobylinux を mobilinux(moblin)と勘違いして、そういえばこれって MontaVista がやってたんじゃなかったっけ?といろいろ調べて、結構時間を無駄にしてしまいました。ガラケー時代に NEC なんかと組んでましたね、MontaVista。

VHDXファイルの容量は小さくできない?

さて、いろいろイメージを pull してコンテナ作って、なんてやっていると VHDX ファイルがどんどん大きくなっていきます。家では ArchLinux 入れてちょっといじっただけで 1GB 超えました。もっとも、VirtualBox でManjaroLinux で遊んでたら、そちらは 21GB を超えているのでたいしたことないとも言えますが、C:ドライブは SSD なのであまり大きくなるようだと困ります。

次のやり方で圧縮できました。あらかじめ pull していたイメージとコンテナは全部削除しています。
  • まず、「Hyper-V マネージャー」で "MobyLinuxVM" を「停止」します。
  • 次に Windows PowerShell を管理者モードで開きます。
  • PS C:\WINDOWS\system32> cd "C:\Users\Public\Documents\Hyper-V\Virtual hard disks"
    PS C:\Users\Public\Documents\Hyper-V\Virtual hard disks> Optimize-VHD -path .\MobyLinuxVM.vhdx -Mode Full
  • これで圧縮(というか未使用領域の開放)が始まり、だいたい 613MB まで縮まりました。もしかしたらこれが最小サイズかもしれません。

コンテナを間違ってたくさん作っちゃったんだけど

start / stop じゃなくて run を使うと新しいコンテナができてしまいます。コンテナが増えると VHDX ファイルのサイズも増えます。なのでコンテナの状況をひと目で分かるようになると便利です。
これを行うのが Kitematic という GUI アプリのようです。ただ、このページにはちょっと気になることが。
Legacy desktop solution. Kitematic is a legacy solution, bundled with Docker Toolbox. We recommend updating to Docker Desktop for Mac or Docker Desktop for Windows if your system meets the requirements for one of those applications.
legacy という単語は、こういうコンテキストで使われたときには「時代遅れ」とか「過去の遺物」というニュアンスがあって、システム要件が合うなら Docker Desktop をおすすめします、とのことです。Kitematic の代わりとなるものは示唆されていませんが。

Kinematic はここからダウンロードするか、タスクバーの Docker アイコンを右クリックして出るメニューから "Kitematic" を選択すると ZIP ファイルをダウンロードします。
早速 ZIP を展開して、出てきた Kitematic.exe を実行してみましたが、どうやらコンテナが起動していないとダメっぽいです。ということでペンディング。

アプリの導入前に構築できるか試したい

それこそ仮想環境の出番ですね。今回も uWSGI が Windows をサポートしないことに気づいたというきっかけがあっていじり始めてますし。

随時思いついたら追加していきます。

ところで、Docker をいじったきっかけは uWSGI なんですが、もしも Docker を使うとして、どういう構成がいいかを考えていました。
まず、データベースはメンテナンスを考慮すると、ホスト側にインストールするしかないでしょう。

ローカルのほうが最新ですの警告。

ManjaroLinux でパッケージマネージャを使っていると、しばらく前から「ローカルの xx のほうが最新です」の警告が出るようになりました。

気になったので調べてみたら、pacman -Syuu して該当パッケージをダウングレードするといいらしいです。
問題のパッケージは mesa 関連で、バージョン番号の付け方がそのパッケージだけ変更されていて、それでコンフリクトが起きたのかなと思いますが、これででなくなりました。

ボリュームコントロール+がバージョンアップしてアラームが鳴らなくなった件。

ボリュームコントロール+(旧Persist+)がバージョンアップして、たぶんこれまでは Android 8(Oreo)の上でちゃんとバックグラウンド動作してなかったんじゃないかと思いますが、逆にそれがちゃんと動作するようになって、夜間設定とぶつかっているのか、アラームが鳴らなくなりました。4月14日に更新されたようですが、新機能の説明が次のようになっています。
  • Fixed a bug with preset schedulers on some devices
  • Added the ability to take the device out of Do Not Disturb mode when changing the volume
  • Added instructions to hide the persistent "Volume Control is running" notification. The notification was added to keep the app running reliably in the background, but it can be hidden on Android 8.0 (Oreo) and above.
いくつかのデバイスでプリセットスケジュールのバグがあったのを修正した、ボリューム変更時に "Do Not Disturb" モードから抜け出す機能を追加した、永続的な「ボリュームコントロールが動作しています」通知を隠す方法を追加した。通知はアプリをバックグラウンドでしっかりと動作するようにキープするために追加されたが、Android 8.0 以降では隠せるようにした。

やっぱりここらへんが怪しいです。また、時計アプリとして HTC のものと Google のものと2つあるのも混乱の元かもしれません。
ともあれ目覚ましが鳴らないのはいただけないので、ちょっと設定を変更しながらチェックです。

Docker Desktop for Windowsを使ってみる。

Docker Desktop for Windows を使ってみます。
ダウンロードは Docker Desktop for Windowsのページからできますが、まずユーザ登録が必要です。
Docker Desktop for Windows is Docker designed to run on Windows 10. It is a native Windows application that provides an easy-to-use development environment for building, shipping, and running dockerized apps. Docker Desktop for Windows uses Windows-native Hyper-V virtualization and networking and is the fastest and most reliable way to develop Docker apps on Windows. Docker Desktop for Windows supports running both Linux and Windows Docker containers.
Docker Desktop for Windows は Windows 10 で動作するように設計された Docker です。ネイティブな Windows アプリケーションで、ドッカライズされたアプリをビルド、シップ、起動するための簡単に使える開発環境です。Docker Desktop for Windows は Windows のネイティブ Hyper-V 仮想化およびネットワーキングを利用していて、Windows 上での Dockerアプリを開発する最も速く信頼性の高い方法です。Docker Desktop for Windows は Linux と Windows 両方の Docker コンテナをサポートします。

Docker には2種類あるようで、Stable channel は4ヶ月毎の更新で、使用統計データを Docker に送るか送らないかを選べます。Edge channel は不安定なこともあるかもしれないけれど頻繁にバグ修正などが行われますが、使用統計データを Docker に送ります。
試しに使ってみるだけなので、ここでは Stable channel を選びます。
インストールが終わるとログアウトを求められます。ここでは再起動までは不要のようです。
再度ログオンすると、次のようなダイアログが表示されます。
「Hyper-V を有効化するけどいいですか?自動的に再起動しますけど。あと VirtualBox は動かなくなりますけど」とのこと。ここは「OK」します。
当然、自動的に再起動します。おそらく Windows コンポーネントの Hyper-V を有効にしてるんでしょう。
確認したらやっぱりそうでした。
デスクトップに "Docker Desktop" アイコンができています。
なんかクジラが荷物運んでます。
が、クジラをクリックしても何も起こらないので、まずは初心に戻って Get started with Docker for Windowsを読んでみます。
Docker is a full development platform for creating containerized apps, and Docker Desktop for Windows is the best way to get started with Docker on Windows.
Docker はコンテナ化されたアプリを作成するフル開発プラットフォームで、Docker Desktop for Windows は Windows 上で Docker を始める上でベストな方法です。
だそうです。

それでは早速コマンドプロンプトを起動して、docker --version を入力します。
$ docker --version
Docker version 18.09.2, build 6247962
次に、hello-world を pull します。
$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:92695bc579f31df7a63da6922075d0666e565ceccad16b59c3374d2cf4e8e50e
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/
pull だというのにコマンドは run のようですが、Docker Hub からなにやらダウンロードしてきました。
再度 dcoker run hello-world すると、上のメッセージの "Hello from Docker!" 以降が表示されました。どうやらそれがアプリの実行結果のようです。でもカレントディレクトリには hello-world はありません。

ちょっとディレクトリを調べてみると、%USERPROFILE%\AppData\Local\Docker にログファイルが、%USERPROFILE%\AppData\Roaming\Docker にはいくつかの .json ファイルがあります。また、\ProgramData\DockerDesktopにもファイルがあります。が、どうにも hello-world は見つかりません。

検索してみると、Forum に回答がありました。
C:\Users\Public\Documents\Hyper-V\Virtual hard disks に保存されているとのことです。
このイメージの保存場所を変更するには、「Hyper-V マネージャー」から行うのがよいようですが、とりあえずおいておきます。

Docker Hub を検索したら、ArchLinux があったので、これを使ってみます。
$ docker run archlinux/base
Unable to find image 'archlinux/base:latest' locally
latest: Pulling from archlinux/base
f3e37ac93b0e: Pull complete
Digest: sha256:f9496957524a239cf60cd0adb0a84ae633c0b712364988cd113e4fc66cdb8b7e
Status: Downloaded newer image for archlinux/base:latest

$ docker run archlinux/base
…何も起こりません。実はどうやらこれだけだと、仮想環境を起動してすぐに終わっている、ようです。以下のようにすることで、/bin/bash が起動します。
$ docker run -it archlinux/base /bin/bash
[root@95b5542f9322 /]# uname -a
Linux 95b5542f9322 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 GNU/Linux
ここで pacman を使ってみると、ちゃんと使えました。
さらに Get started with Docker for Windows に沿って進めると、今度は Nginx を走らせようとしています。
$ docker run --detach --publish 80:80 --name webserver nginx
docker run --help すると、--detach は「コンテナをバックグラウンドで走らせ、IDを表示する」、--publish 80:80 は「指定されたポートをホストに開放する」、--name webserver は「コンテナに名前をつける」だそうです。
対象的に、--attach というオプションがあって、これは STDIN/STDOUT/STDERR をコンテナにアタッチするという指示のようですから、--detach はその逆かもしれません。--publish の "80:80" は、コンテナ内のポート 80 をコンテナ外のポート 80 と接続する、というイメージです。
--name webserver で "webserver" という名前をつけていますが、これはコンテナを停止するときに利用できます。docker container stop webserver でバッググラウンドの Nginx が止まります。
また、コンテナの削除は docker container rm webserver で "webserver" コンテナが削除されます。ただしイメージ "nginx" は残ります。イメージを削除するのは docker rmi nginx です。ただし、そのイメージを参照しているコンテナがあると削除できません。なので docker container ls --all で停止しているコンテナも含めてすべて確認します。
"run" コマンドではコンテナを新規に作成しますが、すでにあるコンテナを開始するには docker container start とします。必要に応じて "-i" (interactive)オプションを指定します。

以上を踏まえると、Windows 上では動作できない uWSGI などは、Docker 上の Linux で動作させてしまえば、あとは TCP ポートを開けてやることで通信できる、ということになります。ただ、設定ファイルなどはイメージ内にあるのでシームレスにアクセスできないという点は面倒そうです。逆にローカルドライブはコンテナ内の Linux からマウントすることでアクセスできるようです。

コンテナ内から Docker を proxy してホスト PC から外部にアクセスできるので、モデルとしては、
Nginx (Windows) <-> uWSGI (Docker) <-> MariaDB (Windows)
などということもできそうです。

が、冷静に考えると、uWSGI を動かすために数百 MB のディスク領域と大量のメモリが必要です。これは開発用とかテスト用ならまだしも、本番ということなら「なんで Linux でやらないの?」ということになりますね、確実に。しかもコンテナの中で変更されたファイルは、履歴管理がやっかいです。これは相当分が悪いと、少なくとも自分的には考えてしまいます。

Windowsでシンボリックリンクを試してみる。

きっかけは、1つのファイルを別の名前で起動したら違う動きになるようなスクリプトを書く、でした。  busybox なんかでは、同じ実行形式ファイルの名前を、lsにすればlsと同じ、cpとすればcpと同じ動作をするようにしてますが、Pythonスクリプトでそれと同じように argv...