OGR-28終了、そしてOGR探索プロジェクトの休止（お気持ち表明）
distributed.netから、OGR-28の探索終了の発表とともに、OGR-29の探索は行う予定がない旨のアナウンスが行われた。
statsを見返すと、2002年の1月にdnetcに参加している。当初RC5-64にも参加したものの、既にアメリカが輸出可能な暗号強度を128bitに緩和していたこともあって、じきにOGR探索に注力することになった。
以来20年間、PCのCPU選択の基準は「OGRが速いかどうか」であり続けた。
はじめてLinuxに触れた理由は、クライアントを動かすためだけに作るPCのOS代をけちるためだったし、Q6600に浮気した一台を除いて、一貫して（PCのCPUとしては）AMD信者だったのもOGRが速いからだった。
Athlon X2が出たときは、「1台で倍のスコアが稼げる！」と喜んだし、PS3がすごいと聞けば、なんのかんので6台（初期型3、プロセスルール縮小版3）買った（初期型の廃熱はすごかった）。
そのうち、複数台のPC管理に嫌気が差し、Dual CPUを検討していたところ、ASUSがKCMA-D8というATXサイズのDual Opteronマザーをリリースしたと聞いて思わずポチってしまったのも良い思い出である（その後、supermicroのH8DCL-iとあわせて10台のATX Dual Opteron機を組むことになる）。コストとメンテ性の兼ね合いから、ケースはThree Hundred、電源はSeasonic 500Wクラスの組み合わせが通例になった。
最近では、Ryzen9 3950X＋ASUS ROG-STRIX-X470Fの組み合わせで2,000Mnodes/secのスコアが出ているのを見て、時代の変化に感嘆していたところであった（クライアントの大幅な改善があることもあって比較はできないのだが、Athlon 1.4GHzで17Mnodes/secほどであった）。
今まで生きていた年数のうち、文字通り半分弱を、dnetcのOGR探索プロジェクトとともに過ごしてきたのである。
そのOGRが、終わってしまった。
ここ最近、久方ぶりにdistributed.netのDownloadページを閲覧しながら、OGR-29用のクライアントが、いつ配布されるのかを楽しみに待っていたというのに。
OGR-29はやらない、という。
Ryzen9 5950Xでクライアントを動かす日を楽しみにしていたというのに。
RC5-72はやる気が起きない。もっと長い暗号鍵が使える今、いまさら72bit暗号の強度が低いことをアピールしてどうするというのだ。俺は学問的な探求がしたい（あるいは学問的な探求をしていると思いたい）のだ。
ああ。
OGR-29やってくれないかな。
confをいじってSambaを設定できるようになった
ようやくコンフィグファイルをいじってSambaを設定できるようになったので，備忘として記載する。
$sudo apt install samba の次に，
$sudo pdbedit -a [User] でsambaにユーザー登録するそうだ。
その後，共有ディレクトリを777で設定し，
/etc/samba/smb.conf を次のとおり設定する。
(1)既にある[gobal]直下に，
dos charaset = CP932
(2)WORKGROUPはいじってないのでそのままで，
(3)###Networking### の「;interface」のところを，
interfaces = 192.168.[***].0/24 eth0
と修正する（セミコロンを消して修正する）
(4)同じく###Networking### のところで，
bind interfaces only = yes （セミコロンを消す）
map to guest = bad User
※Windows10ユーザがAAAで，かつ，SambaユーザにAAAがいないとき，ゲストユーザとしてログインさせるという設定（だが，Windows10はこういう対応を拒否して接続を切ることがあるらしい。幸いうちはLinux/Windowsのユーザ名を同じにしていた。）。不明ユーザに対しユーザ名とパスワードを入力させる設定にすればこれは回避できるそうである。この場合の設定は，
map to guest = never
である。
(5)最後に，共有するディレクトリ情報を書き込む。
[share] #Windowsから参照するときのディレクトリ名
path = /mnt/[******] #共有ディレクトリのパス
writable = yes #read only = No でも良い？
guest ok = yes #guestログインを許可
guest only = yes #どのユーザもguestとみなす（反証不可）
create mode = 0777 #ファイルのパーミッション
directory mode = 000 #ディレクトリのパーミッション
(6)testparm コマンドで間違いないかをチェックでき，
「Loaded services file OK」と出れば問題なし。
あとは，smbd/nmbdを再起動させればよい。
Excel覚え書き(備忘録)
1,「R1C1形式」という表示方法があること。
2,「オートフィル」=「R1C1形式での相対表示(=R[*]C[*]のコピペ」と表現できること。
3,INDIRECT関数を使えば，文字列を数式に読み替えることができること。
4,SUMPRODUCT関数を使うと，条件の一致するものを抜き出すことができること。例)「第1列の7,17,27･･･97行目までの総和」
=SUMPRODUCT((MOD(ROW(R1C1:R100C1),10)=7)*1,R1C1:R100C1)
5,セルの行を返すROW関数，列を返すCOLUMN関数，○で割ったときの余りを求めるMOD関数。なお上記MOD関数の使い方は，
「行(ROW)を10で割って(=MOD(ROW(～)，割る数)，7余る(=7)」という命題につきTRUEかFALSEかを返すものとなっている。
6,かように，TRUE/FALSEを返す関数の場合，「1」を掛けると数字になる。前記の場合は，範囲指定でやってるので，数列になる。
7,数列同士を掛け合わせた和を求めるのがSUMPRODUCT。TRUE=1,FALSE=0と数字(数列)化した上で，それ自身とかけると，TRUEを返したものの総和を求めることができる。
8,SUMPRODUCT関数を濫用しすぎると，循環参照が生じてしまう。複数回の計算を繰り返させることで回避できるが，根本的でないし時間がかかるので，SUMPRODUCT関数の濫用は抑制する必要がある。
9,膨大な量の関数を扱う場合，コピペが不能になる。対処方法は，①「オプション」「詳細設定」（表示）（ハードウェアアクセラレータの無効），②「オプション」「全般」（インターフェイスのオプション）（ミニツールバーの非表示・クイック分析オプションの非表示・リアルタイムプレビューの非表示）で，かなり軽くなる。
10,ほんとはVBAを学ぶべきなんだろうけどなあ。
SSHポートフォワーディングの設定2(鍵の設定)
さて，ユーザIDとパスワードで誰でもSSHにログインできる･･･となると，いささか心許ない。そこで，鍵による認証も設定することにする。
１，鍵の作成･･･の準備
Windows機でSSHサーバにログインするのだから，Windows機に秘密鍵，SSHサーバに公開鍵を設置して認証を行うことになる。となれば，Windows機でペアとなる鍵を作成し，SSHサーバに公開鍵を送付するのが筋だ。SSHサーバで鍵を作成するのでは，秘密鍵をどうやってWindows機に安全に送付するのか，という問題が出てくる。
ところが，Windows 10にはペアとなる鍵を一発で作成するコマンドがない(linuxにはある)。そこで，linuxコマンドをWindowsでも使えるようにする，Git for Windowsというツールをインストールすることになる。
検索してダウンロードして，全部初期設定のままEnter連打でOKであった。
２，いよいよ鍵の作成
cortanaさんに"git"と入力すると，「Git Bash」が出てくるので，こいつを起動させる。
鍵作成のコマンドは，
<追記>
ubuntu 22.04 LTSで採用されているOpenSSH 8.9p1のひとつ前，OpenSSH 8.8から，デフォルトではSHA-1 RSAが無効化されたとのこと。ssh-keygen -t rsaで生成される鍵はSHA-1 RSA方式による鍵なので，こいつは使えない。（面倒くさがらずにログをきちんと調べればよかった。ログの場所は，/var/log/auth.log）
$ssh-keygen -t ecdsa -b 521
で，ecdsa-sha2-nistp521という強い暗号方式による鍵を作れるそうだ。楕円曲線だとかいうらしい。
鍵の出力先についてこれでいいかフルパスで聞かれるので，OKする。確かデフォルトでは，"C:\Users\(ユーザ名)\.ssh"フォルダのはずである。
パスフレーズを入れてくれと言われるので，入力する(2回)。これで，鍵とパスフレーズの双方がないとログインできなくなる。
これで，公開鍵(id_rsa.pub)と秘密鍵(id_rsa)のペアが作成された。
あとは，適当な方法で，公開鍵をSSHサーバに放り込む。
３，sshdの設定(1)
次はssh daemonの設定を行う。設定ファイルは，/etc/ssh/sshd_config なので，viとか適当なエディタで編集する。編集するところは，
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
の2行について，コメントアウトを外す。これで鍵による認証が行われることになる。
なお，ubuntu 18.04 LTS では，公開鍵ファイルが2箇所に格納されているが，使うのは上記の home/(ユーザ名)/.ssh/authorized_keys だけにする。
４，sshdの設定(2)
さて，sshdが参照する公開鍵の場所が分かったので，放り込まれた公開鍵の内容を，.ssh/authorized_keys に差し込む。コマンドは，"cat"コマンドを使う。
$cat id_rsa.pub >> home/(ユーザ名)/.ssh/authorized_keys
準備を終えたら，sshd_configに間違いがないかどうかテスト。
$/usr/sbin/sshd -t ※フルパスで指定する
$ ※間違いが無ければ何も表示されない
問題がなければ，sshdを再起動。
$sudo systemctl restart sshd
５，接続テスト
tera termで接続する際，ユーザ名，パスフレーズ，秘密鍵ファイルの指定を行って接続すると，うまくいく･･･はず。
うまくいかなかったら，もういっかい戻る。
６，ユーザ名とパスワードだけのログインを拒否
さて，もう一度SSHサーバに戻り，sshd_configの次の行を編集する。
#PasswordAuthentication yes
のコメントアウトを外して，"yes"を"no"にする。で，sshd再起動。
これで，ユーザ名とパスワードだけではログインできなくなる。
７，秘密鍵のコピー
別のPCからもSSHサーバにログインするようなときは，先ほどつくった秘密鍵を，別のPCにコピーすればよい。
SSHポートフォワーディングの設定
自宅～職場間でPCを遠隔操作する場合，Google Remote Desktopが便利である。しかし，昨今のリモートワークでサーバが混雑しているせいか，応答が遅いことがままある。VNCでつないでしまえば速いのだが，そのままではセキュリティが不安である。
ということで，SSHポートフォワーディングでVNCを接続することにしたので，その設定の備忘録である。
(1) 外部端末から，グローバルIPアドレスが付与されている自宅のルータのポート22にアクセスする。
(2) 自宅のルータは，WAN側ポート22に入ってきた通信を，LAN内SSHサーバのポート22に転送する。
(3) これで，外部端末とLAN内SSHサーバとの間で，暗号化通信が確立される。
(4) このSSH通信に，「自宅WindowsマシンへのVNC接続」を「載せる」。
(5) そうすると，自宅WindowsマシンへのVNC接続が，SSHにより暗号化される。
１，SSHサーバの設定
基本的に何かをする必要はない。ただし，ポート22(SSHの初期ポート)を開けっぱなしにするというのは感覚的に気持ち悪い。そんなの気休めだ意味は無い，というのも分かるけれど，一応ポートは変えておきたい気分である。
が，突然変えてしまうというのも，設定を間違えたときに再ログインできなくなって不便である。で，なるほどと思ったのが，SSHの設定でポート22と，たとえばポート222の双方を受け付けるようにして，ポート222での設定がうまくいったらポート22をルータで塞ぐなり，削除するなりする，というやり方。
ポートに関する設定ファイルは，
なので，そこの
#Port 22
の行の下あたりに，使うポートを指定して書き込む。こんなふうに。
#Port 22
Port 22
Port 222
これで，ポート222でも，22でも，SSHがつながることになる。うまくいいくことが分かったら，"Port 22"の行を削除すればよい。
設定したら，
sudo systemctl restart sshd
でsshdを再起動する。
２，自宅ルータの設定
いわゆるポートフォワーディングの設定を行う。WAN側ポート222に入ってきた通信を，SSHサーバのポート222に転送する設定を行えばよい。
どうも自宅のルータは，転送先のPCをIPアドレスで指定するようである。自宅LAN内のIPアドレスは，DHCPで振っているので，本当はこういう直接指定は良くないのだろうが，実用上問題ないくらいには変わってないので，よしとする。
３，外部端末の設定その１
外部端末にTera Termをインストールする。問題なく終了するはず。
Tera Termで，接続先を，「自宅ルータのグローバルIPアドレス:222」と指定すると，自宅ルータがポートフォワードをしてくれて，SSHサーバのポート222に通信が転送されるので，Tera Termで自宅SSHサーバにログインできるようになる。
４，外部端末の設定その２
Tera Term丈夫メニューの「設定」－「SSH転送」をクリックすると，ポート転送の設定画面になる。転送ルールを設定するので，「追加」ボタンをクリックすると，「ポート転送を行う向きの選択」という画面になる。
その画面で，「ローカルのポート」を選択し，適当な数字，たとえば「33890」と入力する。「リッスン」は空欄にする。
「リモート側ホスト」には，自宅WindowsマシンのプライベートIPアドレスを指定し，「ポート」には，自宅WindowsマシンのVNCサーバが使用しているポートを入力する。自宅WindowsマシンのVNCサーバが「33891」で待ち受けているならば，「ポート」には，「33891」と入力する。
あとは，OKを押して設定メニューを閉じる。
その後，再び「設定」－「設定の保存」で，設定内容を保存する。
５，Tera Termの再起動
Tera Termを一旦閉じて，再び起動し，上記「３，」の手続を踏んでSSHで接続する。
６，VNCクライアントの設定
外部端末のVNCの設定画面において，localhost(127.0.0.1)のポート33890を接続先に指定する。
これにより，VNCクライアントは，自身のPCのポート33890に接続しようとし，そこでSSHの設定により宛先を「自宅WIndowsマシンのポート33891」に書き換えられ，VNCの通信は，SSH通信に「載せられる」ことになる。
あとは，SSHサーバ側でSSHによる暗号化が解かれ，そうすると出て来た通信は「自宅WIndowsマシンのポート33891」宛てということになるから，SSHサーバは自宅Windowsマシンのポート33891宛てにその通信を転送する。
７，かくして，外部端末のVNCクライアントは，自宅WIndowsマシンのVNCサーバと通信することが可能になる，というわけである。
８，Tera Termのターミナルを閉じると，VNC通信も閉じてしまうので，VNC通信がSSH通信に「載っている」ころがわかる。
備忘録(Windows10に紐付いたMicrosoftアカウントの切り替え)
Windows10のサインインは複数の方法が選べる。便利なのはMicrosoftアカウントでのサインインだが，1人のユーザーがMicrosoftアカウントを複数(AとB。職場用・個人用など)持っているとき，AのアカウントでサインインしたいのにBのアカウントでサインインしてしまう，ということがしばしば発生する。
Windowsのサインインユーザーを切り分け，ローカルアカウントaはAというMicrosoftアカウントにし，ローカルアカウントbはBというMicrosoftアカウントにし，ユーザーはaとbとを使い分ける･･･とすればそういうことも起こらないのだが，面倒である。かくして，ローカルアカウントaというユーザーが，MicrosoftアカウントA/Bの双方をアカウントaで使用することになり，上記の事態が発生するのである。
いったんローカルアカウントaとMicrosoftアカウントAの紐付けがなされると，Windowsサインインで表示される「a」という表示は，MicrosoftアカウントAの表示名に切り替わる。このとき，紐付いていないMicrosoftアカウントBは，「サブアカウント」的な位置づけとなっており，Windowsのアカウント管理画面（「メールとアカウント」のところ）から削除することができるが，紐付いているMicrosoftアカウントAは，「メインアカウント」的な位置づけとなっているため，削除することができない。
ところで，何かの拍子に「a」のMicrosoftアカウントとの紐付けが，AからBに切り替わったとする。そうすると，今まで「a」でログインしたとき表示されるのはMicrosoftアカウントAの表示名だったのが，MicrosoftアカウントBの表示名に切り替わってしまう。ユーザー情報で示されるメールアドレスも，MicrosoftアカウントBのものである。そして，「A」に戻したいと思っても，方法が見つからず，じゃあいっそMicrosoftアカウントBを削除してしまおうか，と思ってもコンピュータからMicrosoftアカウントBを削除することができない(メインアカウント的な位置づけになってしまっているため)ので途方に暮れるのである。
これの対処法，つまりMicrosoftアカウントを複数もっている場合に，サイインイン情報と紐付けるMicrosoftアカウントを変更する方法は，
・ローカルアカウントaが作成済みのユーザーであれば，「ユーザー情報」から，「ローカルアカウントでのサインインに切り替える」を選択していったんローカルアカウントaでのサインインに戻した後，再び「Microsoftアカウントでのサインイン」を選択し，MicrosoftアカウントAの情報を入力するようにする。
・ローカルアカウントが作成されていない(表示されない?)ユーザーの場合，「ローカルアカウントでのサインインに切り替える」が表示されず，代わりに，「すべてのMicrosoftアプリへのログインを自動的に停止」が表示される。これをクリックすると，Microsoftアカウントとの紐付けが解除されるので，改めてMicrosoftアカウントAへの紐付けを行う。
MicrosoftアカウントAでWindows10にサインインしているが，MicrosoftアカウントBでWindows10にサインインしたいというときは，「Microsoftアカウントを切り替える」という発想ではだめなのである。
「(場合によっては隠れている)ローカルアカウントとの紐付けを解除してクリーンな，つまり紐付いていない状態に戻す」ことが必要なのである。
･･･ちょっと文句言いたい。「メールとアカウント」のところにMicrosoftアカウントが二つ並んでいるのだから，そこで何とかするもんだと思ってしまうではないか。
あるいは，Microsoftアカウント関係の処理だから，「ユーザーの情報」の「Microsoftアカウントの管理」かと思ってしまうではないか。
よしんば「ローカルアカウントでのサインインに切り替える」は分かったとしても，「Microsoftアプリのログインを自動的に停止」が解とは思わないだろう。せめて，「Windowsを含むすべてのMicrosfotアプリについて，現在使用中のMicrosfotアカウントによるログインを自動的に停止する」とかの表現にならなかったものか。
※ちなみにMicrosoft的にはサインインとログインはどう違うんだろ。
