故郷で「アクセントプラス」を営む旧友N氏からのプレゼント「ステムキャップ」を愛車Tern Crestに装着しました。（遅すぎー）
AccentPlusではNC彫刻機（NCフライス）を用いて樹脂類、木材、金属類などを削り出し製作するオリジナル製品や、既製品に彫刻加工することによって新たな価値を付加するなど、この世界に一つしか存在しない特別な物を提供します。
この「NC彫刻機」というやつがありきたりなレーザー彫刻やプリントとは違う風合いをもたらすのである。
「良いね！」と思われた方は是非こちらからお問い合わせください。気さくなオッチャンが親切丁寧に対応致します（笑）。
（本記事は「現時点で私はこう理解している」というだけで、それなりに正しいとは思っているけど、間違っているかもしれないし、何の責任も負わないし、負えません。念為。）
キャパシティ目一杯のPCR検査が行われていない事を嘆く人が多い。スペック通りの検査件数をこなせない要因は人的リソース不足にあると推測しているが、ここ数日の検査件数が減っているのは別の理由、すなわち「単に検査が必要な患者が少ないだけ」なのであろう。結構なことである。
そもそも「COVID19」とは何か？ざっくり言えば「質の悪い風邪」だ。感染力があり、重症化したり死亡したりする確率が少し高いが、多くの場合は自然に治癒する。インフルエンザみたいな病気だと言える。
インフルエンザみたいな病気なのだとしたら、世界は何を恐れているのか？
要治療患者の爆発的な増加
である。
人の体はウイルスに感染すると抗体を作り出す。例えばインフルエンザの場合、既に多くの人が抗体を持っているので、季節的な流行があるにしても患者数は限られる。毎年恒例であるから、それに対する医療のキャパシティが十分なのは身をもって知るところだ。
（インフルで病院に行って追い返されたなんて話は聞いたことないでしょ？）
しかし、COVID19の原因となるウイルスは「新型」なので、ほとんどの人類は対応できる抗体を持っていない。ここが決定的に違う点だ。放っておけばどんどん感染してどんどん発症する。医療のキャパシティを容易にオーバーする。
医療のキャパシティを超える数の要治療患者が出てしまうと、治療が行きわたらないので助かる命が助けられなくなる。もちろん他の病気の患者への対応も難しくなる。「医療の崩壊」と言われる状態で、これが最も懸念されるワケ。
今実施されている様々な施策の目的は「新たな感染を絶対に起こさないこと」でも「COVID19を根絶やしにすること」でもない。「急激な患者数の増加を抑えること」なのである。つまり、やたらと検査をして感染者を抜け漏れなく見つけ出す必要はない。
あなたが重症でないのなら「感染していること」を知る意味はない。重症でないなら治療の必要も方法もないからだ。「感染していないこと」を知る意味もない。抗体を持たない以上、近い将来に高い確率で感染することになるからだ。
ただし、軽症でも「それらしい症状」が出ている場合、感染している可能性を考えて他の人に感染させない努力をしなければならない。それは「急激な患者数の増加を抑える」ためであり、「死亡率が高いお年寄りや基礎疾患のある人の命を守る」ためでもある。
「感染していなかったら無駄な努力になるから検査して欲しい」と言うなら、それはおかしな理屈だ。COVID19でもインフルエンザでもタダの風邪でも、それを人にうつすべきでない。どちらにしてもCOVID19であるか否かを判定する必要はない。
PCR検査は「重症者の診断確定」や「感染経路の調査」や「感染者数の推計」のためもので、それと関係ない人が検査をしてもらう意味は全然ないのである。今は「感染しない努力」と「感染させない努力」を欠かさず、大人しく過ごすのが世のため人のため自分のためである。
まぁ、以下のサイトに同じような意味のことが書いてあるんだけどねコレ。
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000164708_00001.html
（上記サイトより引用）
政府の対策は素人目には後手だったり場当たり的だったりするが、結果的にはそこそこ上手くやっていると考える。PCR検査を大胆に実施した韓国やイタリアも、現在は日本の手法を後追いをしている状態で、どこも試行錯誤なのだ。
これから感染が増えそうな国はどう対処するのだろうか。先行して迎え撃った中国は「一抜けた」で経済回復してますます栄えたりして。それはそれで結構なことである。我々も頑張らねばならない。手洗いが日本を救う！（笑）
さて、人類がうまくピークを乗り越えた後、COVID19はどうなるのか？
この手の感染症の末路にはいくつかパターンがあるそうだ。なんとなくだが、１～２年で世界中の多くの人が感染して（＝風邪をひいて）それと気づかないまま抗体をもつのではないか？その後は時々流行する程度の、文字通り「インフルエンザみたいな病気」として定着するのではないか？と思っている。
トイレットペーパーが買い占められた問題。備品の窃盗や転売目的での購入は非難したいが、多くの人が購入に走るのは致し方ない事だ。「とりあえず買っとく」のが普通の行動パターンですよ。腐るもんでもないし。
それにしても「買えなくて切羽詰まった」という人が多い気がする。消耗品をストックしない人が多いのだろうか？トイレットペーパーのラスト１ロールを使い始めたらコンビニで買ってくる、なんて生活しているのか？
さて、発端となった新型肺炎である。検査は期待通り進まず*1、企業は休業もままならず、学校が休校しても現場が混乱するばかり。特に休校については子育ての経験から想像される通りの状況で『終わっててラッキー』なのだが、これらはすべてにおいてマージン（余裕）がないやり方が横行している事に原因があるように思う。
組織にも人にも物資にもマージンがないから変化に対応することができないのだ。表面的にはお金の問題に見えるかもしれないが、根本的には手法や価値観の問題だ。長いことマージンを切り詰める経営や生活を継続して積み重ねてきた結果なのである。
派遣や非正規雇用の問題は代表的で、雇用する側の効率化のために雇用される側のマージンを切り詰めるものだ。大都会も最たるものであろう。常に満員＆行列＆渋滞であり、あらゆるマージンを切り詰めて効率のために全てを捧げた世界だといえる。
どちらも個人のマージンを削り取って犠牲にしているのだから全体としては効率は良いように見えるが、犠牲となった個人は幸せといえるのか。そして、マージンのない世界はちょっとした変化で簡単に破綻する事を我々は知っている。
電車１本止まれば、、、
大雨が降れば、、、
地震が起きれば、、、
疫病が発生すれば、、、
トイレットペーパーが店頭から消えたら、、、
あなたは「トイレットペーパーが店頭から消える」という変化に対応できただろうか？
満員電車で通勤し、足蹴くコンビニに通い、トイレットペーパーを置く余裕もないウサギ小屋に住む。それを「便利」と称して自らのマージンを削り取られる生活で、幸せになれるんだろうか？
単に「備蓄せよ」ということではない。価値観を転換すべき時なのだ。気付いた人は、とりあえず新潟に引っ越してきなせ。（そこにつなげるのか！＞俺）
以下余談。
我が家では以下が常時ストックされるよう努力している。基本的にズボラであり消費と補充のペースが合わずに切れているタイミングもあるので自慢はできないのだが。
水ペットボトル
カセットガスボンベ
パックご飯
インスタント食品類
缶詰類（犬用含む）
ラップ類
紙類
電池類
これに加えてカセットコンロの他、電源の要らない灯油ストーブとカセットガスを使用するポータブルストーブを備えている。
通常は自然災害を想定して「３日位は飢えない」を目安としているが、現在は新型肺炎対策で食品類を「１０日位」まで増備している。嫁によるとトイレットペーパーは「１か月分くらいある」とのことで、切れる前に店頭で買えない状態は解消すると見込んでいる。
Titan, Unihertz Rugged QWERTY Smartphone
Kickstarterでプレッジしたunihertzの防塵・防滴・耐衝撃・QWERTYキーボードなAndroidスマホ「TiTAN」。ギリギリ年内に間に合いました！
予想していたが「デカい！」「厚い！」「重い！」というのが最初の印象。BlackBerry Key 2 LEを愛用している嫁曰く「キーボードのサイズは羨ましいが片手で持てないのは厳しい」。薄っぺらいヤワなスマホから乗り換えるには少しばかり気合と工夫が必要だ。
（ヤワなスマホの代表として5.5インチのcovia「g07」と比較。高さは同じ位、幅は120%位、厚さは220%位。）
遠慮なく奢られたメモリ・ストレージ・バッテリーに対し、実用品として価格相応に割り切られたCPU・画面解像度・カメラの仕様がなかなか憎い。限られたコストの割り振り方が「解っているヤツ向け」だと言える。
Apple的なスマートさとは無縁のボディは細部まで仕上げが丁寧で、存在感のあるサイズに良く似合う。指紋センサーの感度やスピーカーの音質も良好。リーズナブルながら、所有感を満たす「良いモノ感」はちゃんとある。
キーボードは良好。BlackBerry KEYより高さと幅があるだけでなく、大きめのボディが安定したホールド感をもたらす*1。IMEの「Kita-Keyboard」は普通に使える完成度だが、英語モードで先頭を大文字にしたり自動でスペースが入る機能はお邪魔。お気に入りの「FSKAREN」も試したが、BSキーが動作せずShiftやaltも同時押し必須になるので断念。
スクエアのモニタは「さぞ狭かろう」と思っていたが、使ってみると「横に広くなった感じ」が正しく思いのほか快適。物理的な幅だけでなく「戻る」等のボタンが物理キーなのが効いている*2。16:9の動画を再生してみると、絶対的なサイズこそ普通のスマホの横向きに及ばないが必要十分。
今時のスマホとしてはサイズと重量が規格外である点を呑み込めれば、QWERTYキーボードと玄人好みのスペックを有する、実用性の高い面白い機種だと思う。せっかくなのでメインで使ってみたい。
15日に引退した485系「きらきらうえつ」の最後から３番目の臨時運行になった「きらきらしんえつ」にツアーで乗ってきた時の写真。定期運行で乗れなかったのは残念だけど最後のチャンスで乗れたので良かった。
私は何処でも可能な限りEmacsをインストールする。設定ファイルを弄る程度なのでEmacsのマルチな性能は不要なんだけども、DOS時代からEmacsクローン*1を使っていたので「CUIで使うエディタはemacs」と脳味噌に染みついているのだった。とりあえずviは〇ね（ぉい）
Emacsをインストールすると400MB以上も容量を食ってしまうが（Centos8の場合）、今時のストレージはデカいので問題ないのである。しかし、コンパクトにまとめたいDockerイメージの場合には看過できなくなる。元が300MB位なのに700MBに！これはダメでしょ。
というわけで、サイズの小さいEmacsクローンを探してみたところ「mg」というプロダクトが見つかった。
GitHub - hboetes/mg: Portable version of the OpenBSD maintained mg, micro emacs clone
元々のmgはOpenBSD由来で、libbsdを使用して他でも動くようポーティングされたバージョンだそうだ。有難い事である。
Dockerコンテナ内でmakeしようとするとmakeの時に必要なものまで入れないといけないので、ホストか別のmake用コンテナでmakeし、お目当てのコンテナではmake installで実行される手順を手動で行うことで追加容量を最小限に抑える。
# 標準的な開発用パッケージをまとめてinstall
dnf groupinstall "Development Tools"
# libbsdのdevelパッケージをinstall
# https://pkgs.org/download/libbsd
mkdir work
cd workwget http://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/l/libbsd-0.8.3-1.el7.x86_64.rpm
wget http://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/l/libbsd-devel-0.8.3-1.el7.x86_64.rpmrpm -i libbsd-0.8.3-1.el7.x86_64.rpm
rpm -i libbsd-devel-0.8.3-1.el7.x86_64.rpm# ncursesのdevelパッケージをinstall
dnf install ncurses ncurses-devel
# makeする
# https://github.com/hboetes/mg/
mkdir mg
cd mg/
wget https://github.com/hboetes/mg/archive/master.zip
unzip master.zip
cd mg-master/
make clean
make# 普通にインストールしてみる
make install
# libbsdのパッケージをinstall
wget http://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/l/libbsd-0.8.3-1.el7.x86_64.rpm
rpm -i libbsd-0.8.3-1.el7.x86_64.rpm# ncursesのパッケージをinstall
dnf install ncurses
# make済みmgをinstall
cd work/mg/mg-master/
/usr/bin/install -d /usr/local/bin
/usr/bin/install -d /usr/local/man/man1
/usr/bin/install -m 755 mg /usr/local/bin/mg
/usr/bin/install -m 444 mg.1 /usr/local/man/man1/mg.1ln -s /usr/local/bin/mg /usr/bin/emacs
ちゃんと記録してなかったが確か30MB位で収まってたハズ。許容範囲であろう。いわゆるマルチバイト文字には未対応なのであくまでメンテナンス用だ。
現時点で公式手順に従ってCentOS 8にDocker Engine Communityをインストールしようとすると以下のエラーが出る。
[root@fuga yamagw]# dnf*1
install docker-ce docker-ce-cli containerd.io
エラー:
問題: package docker-ce-3:19.03.4-3.el7.x86_64 requires containerd.io >= 1.2.2-3, but none of the providers can be installed
- cannot install the best update candidate for package docker-ce-3:18.09.0-3.el7.x86_64
- package containerd.io-1.2.10-3.2.el7.x86_64 is excluded
- package containerd.io-1.2.2-3.3.el7.x86_64 is excluded
- package containerd.io-1.2.2-3.el7.x86_64 is excluded
- package containerd.io-1.2.4-3.1.el7.x86_64 is excluded
- package containerd.io-1.2.5-3.1.el7.x86_64 is excluded
- package containerd.io-1.2.6-3.3.el7.x86_64 is excluded
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
「containerd.ioの1.2.2以降が見つからん」とおっしゃる。この対処として「素直に--nobestを指定する」「containerd.ioのrpmを拾ってくる」のいずれでも動くことは動くが、微妙に気持ち悪い。なので「少し前のバージョンのDockerを使う」を試してみる。
まず使用できるパッケージのリストを確認。「yum list --showduplicates」すると過去分も含めてリストしてくれる。
[root@fuga yamagw]# dnf list --showduplicates containerd.io
containerd.io.x86_64 1.2.0-1.2.beta.2.el7 docker-ce-stable
（略）
containerd.io.x86_64 1.2.0-3.el7 docker-ce-stable
最新のcontainerd.ioは1.2.0のようだ。
[root@fuga yamagw]# dnf list --showduplicates docker-ce
docker-ce.x86_64 17.03.0.ce-1.el7.centos docker-ce-stable
（略）
docker-ce.x86_64 17.12.1.ce-1.el7.centos docker-ce-stable
docker-ce.x86_64 18.03.0.ce-1.el7.centos docker-ce-stable
（略）
docker-ce.x86_64 3:18.09.9-3.el7 docker-ce-stable
docker-ce.x86_64 3:19.03.0-3.el7 docker-ce-stable
（略）
docker-ce.x86_64 3:19.03.4-3.el7 docker-ce-stable
docker-ceとdocker-ce-cliについても確認し、両方に共通して存在するバージョンを新しい方から順にさかのぼって試していくと、「18.09.1-3.el7」であればcontainerd.io 1.2.0と組み合わせられることが判った。
[root@fuga yamagw]# dnf install docker-ce-18.09.1-3.el7 docker-ce-cli-18.09.1-3.el7 containerd.io
依存関係が解決しました。
========================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリ サイズ
========================================================================================================================
Installing:
containerd.io x86_64 1.2.0-3.el7 docker-ce-stable 22 M
docker-ce x86_64 3:18.09.1-3.el7 docker-ce-stable 19 M
docker-ce-cli x86_64 1:18.09.1-3.el7 docker-ce-stable 14 Mトランザクションの概要
========================================================================================================================
インストール 3 パッケージ
これでよろしいですか? [y/N]:
よろしいです。インストール後に「docker run hello-world」で確認。
[root@fuga yamagw]# systemctl restart docker
[root@fuga yamagw]# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:c3b4ada4687bbaa170745b3e4dd8ac3f194ca95b2d0518b417fb47e5879d9b5f
Status: Downloaded newer image for hello-world:latestHello from Docker!
This message shows that your installation appears to be working correctly.
（略）
問題ないようですな。さて、このままだと「yum update」する度にエラーが出てしまうので、「docker-ce」と「docker-ce-cli」をupdate対象から除外する設定を行う。
[root@fuga yamagw]# emacs /etc/yum.conf
exclude=docker-ce*
（末尾に追記）
「ん？もしかしてdnf.conf？」と思ったが「yum.conf」は「dnf.conf」のシンボリックリンクになってました。
[root@fuga ~]# ls -al /etc/yum.conf
lrwxrwxrwx. 1 root root 12 5月 14 04:34 /etc/yum.conf -> dnf/dnf.conf
除外したことを忘れないようにしないと延々と古いものを使い続けることになる点は要注意ですな。
