Dropboxの移行先としてのMEGAsyncの評価
mega.nz
フリーアカウントの容量は50GB。3ヵ月ログインなしでアカウント削除*1（実際は8ヵ月くらいまでは待ってくれるらしい。消される一週間前にログインしないと消しますよメールは来る）。
ダメなところ
いいところ
- 同期するフォルダ名を自由に決められる。「MEGAsync」以外のフォルダでもいい。
- 保存される場所が決まっていて変更できないような設定ファイルも同期対象にすることができる
- 同期するフォルダを何個でも指定できる。
- 除外したいファイルパターンを指定できる。
- 同期するマシンの数に制限はない（Dropboxはフリープランは3台までに制限されてしまった(2020年9月現在)）
- ほとんどのOSに対応している？
windows使ってるとHOMEの場所が分散したりパスの問題で悩まされる（愚痴
実に疲れる。
windowsのパスの解釈がおかしかったり、環境変数HOMEを無視するソフトの存在が。*1
環境変数HOMEを設定していようと、ある特定のソフトは関係なくwindowsのユーザプロファイルディレクトリ（C:\Users\{ユーザー名}\）の方を見に行くし、
MSYS2のopenssh は MSYS2の /home/{ユーザー名} の方を見に行く。（go言語やhaskellで作られたソフトとかがそんなことをしてくる）
ここにきて、ghq が、Git bash から起動したときには正常に、ghq.rootに~が含まれているとき環境変数HOMEに解釈してくれるが、MSYS2のシェルからだと~の解釈がおかしいことに気づいた；
環境変数HOMEに D:\home\ を設定していたら、D:\home\ghq ではなく、D:\d\home\ghq をghqルートディレクトリに設定してくる*2。
こんなに苦悶を味わうのなら、いっそのこと環境変数HOMEを設定するのはやめてデフォルトのwindowsユーザプロファイルディレクトリを使ってる方が幸せになれる気がしてきた。
ただ、環境変数HOMEを設定していないとおかしなところにファイルを作られる気がするのと、精神衛生によくないんだが
またはもうwslだけを使うのがいいのだろうが、windowsローカルで動かす方が気持ちがいいからそういうわけにはいかないんだよなぁ。
windowsの中だけで過ごしているうちは幸せで、だが*nix系のツールや作法に足を踏み出すと急激にSUN値が上がっていく。
そう言えばそもそもnvm-windowsをMSYS2で実行できないから仕方なくghqでnodistを取ってこようとしたことから始まったyak shavingだった。
なぜか MSYS2上で nvm use {バージョン番号} しても、nodejsのnpmのPATHが通されないことから始まって、調べてみると NVM_HOME とか NVM_SYMLINK が自動で設定されなくて、仕方なく手動で設定したのに相変わらず nodeに PATH通してくれなくて、こうなったらと直接PATHに nodeのパスを加えてもなぜか削除されて、しょうがないから nvm-windows を使うのをあきらめてnodistを使うようにしたという、もう本当に文字にするとしょーもないことで何時間も使って、挙句にこのPATH問題だぜ？
MSYS2が原因の問題が起きたのは今に始まったことじゃないが、こんなにいろいろ起こるとMSYS2を使うのをやめた方が幸せになれるんじゃないかという気すらしてくる。
↑nvm-windows がうまく動かないときには環境変数NVM_HOMEとNVM_SYMLINKを手動で設定したうえでこの2つをPATHに加えたらいいんだって
参考：nvm-windows 導入 - Qiita
わかるかこんなの！
windowsでMSYS2とWSLとネイティブインストールの使い分け
windows上での開発環境について、かつてはmsys2とそれに付随しているmingwですべてを賄おうとしていたが、msys2/mingwでnodejsがサポート外になったことと、ネイティブでしかサポートしていないアプリや開発環境が増えたこと、そもそもネイティブのPATHにmsys2やmingwのPATHを通すのは間違いのような気がしてきたので、これからの使い分けについて考えてみる。
あと不用意にパソコンを初期化してしまってローカルにあった設定とかわからなくなったし。
追記：nodejs(npm)の補完がmsys2のzshで動いてくれない（というかMingw の bashでしか動いてくれない）ので、zshの上でnpm使う計画は頓挫した。
completion: refused to run under CYGWIN bash · Issue #13624 · npm/npm
yarn なら大丈夫のようだ。
Windowsネイティブ
安定していて互換性あることは保証されるが代償としてレジストリやPATHが汚されていく。
- PATHを通さなければいけない欠点はscoopに任せるのでおおよそ解消される。
- 単体のアプリなら、
scoop\shimsに追加されていくからPATHが無尽蔵に増えていくことはなさそうだが、それでもときにscoopが勝手にPATHを追加していくことはある。例えばnodejsを入れたらscoop\apps\nodejs\currentとscoop\apps\nodejs\current\binを追加された。
- 単体のアプリなら、
- レジストリを汚す可能性がある。scoopに任せてもレジストリは汚れていくんだろうか？
- GUIを開発するならネイティブにインストールするしかない？
- scoopでは使用可能なものが少なく、windowsネイティブでも使用できないツールがある（rbenvなど）。
MSYS2
ネイティブで使えないUnix系のツール（zshとかtmuxとか）を使うときに頼りにする。
- コマンドプロンプト等から呼ぶときにはPATHを通す必要がある。
- windows側のPATHを汚したくないなら同梱されているランチャ(msys2.exe, mingw32.exe, mingw64.exe)から起動するのが基本になる。
- なぜか内部にmsys2とmingwのエリアが分かれてあって、本格的に開発言語をインストールするときにはmingw側にインストールしないと不具合が出る（msys側は言語バージョンが低かったりするんだっけ？それともサポートされてる言語が少なかったんだっけ？忘れたけど）
- mingw側にインストールした言語からwindowsのGUIを開発することができた。100%互換性があるかどうかは不明。
- nodejsがサポートされなくなった（削除された）
- pacman の構文が気に入らない。
欲求
以上を踏まえての方針
- msys2のシェルをメインに使う。
MSYS2_PATH_TYPEをinheritにしてwindowsの環境変数を受け継ぎ、主にscoopで入れたネイティブプログラムも実行できるようにする。 - msys2はmingwを使わずmsys2側だけ使い、役割はツールの提供だけの最低構成にする。
- 実行環境の提供はWSLに任せ、wslコマンドで呼び出すようにする。
- wslで動かない状況が発生したとき、scoopでインストールし、ネイティブで実行する。
- *nix環境で動かすときにはwsl付き、ネイティブで動かすときにはwslなしと、動作環境を明瞭にする。
これまでmsys2のmingwに実行環境を作っていたのをWSLに役割を移す。msys2内のmingwの立ち位置が中途半端だったし、プログラムがmsys側にあるのかmingw側にあるのか気にしたくなかった。
調べたところMSYS2も、自己完結して動くアプリ（エディタやファイラなど）はmsys2側で提供し、実際のプログラミング言語の提供はmingw側に任せmsys2は関知しない方針を貫いているようで、つまりはmingwの代わりにWSLを使っても何の問題もない。
MSYS2にはこういう未来が見えていたのだろうか。
Consider
C言語関係のコンパイル環境は MinGW32/64 を使うか、さもなくば MSVC(Microsoft Visual C++)を使う必要がある（そしてどうもMSVCはVS command prompt から実行しないと動かないそうだ）。こういうことを鑑みると、Windows上で動くC言語系をコンパイルする環境のみ、MinGW32/64 で構築しておくのも一案だ。とはいえWSLのパスにWindowsの$PATHを加える方針でやっていると思わぬ競合が生じそうで怖い（WSLローカルの環境がPATHの前の方に来るとは言え）。まぁ少なくとも、Windowsネイティブで（例えばscoopなどで）makeが提供されるようなことは今後しばらくも起こらないだろうということで、C環境については割り切ってMinGWを使うのもいい。
今のところとりあえず別にmsys2環境を分けて、そちらだけにMinGWの環境を立てているが。
ちなみに msys2/mingw にC環境を構築するコマンドは以下
$ pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain
MSYS2 による gcc 開発環境の構築 ― gcc パッケージ群の導入 | text.Baldanders.info
パッケージグループなので、実際は結構な量のパッケージがインストールされる（pacman -Sg ＜パッケージグループ名＞ でどんなパッケージが含まれているか確認できる）。
windows更新したらNAS（LANDISK-HDL2-A）にアクセスできなくなった。
ネットワークのコンピューター一覧にNASのフォルダが表示されなりアクセスできなくなった。
以下のサイトを参考にSMB 1.0/CIFS共有のサポートを有効にすることで解決した。
itojisan.xyz
注意: ただし、SMB 1.0/CIFS共有のサポート機能は、脆弱性が見つかりWindows 10 ver1803 のアップデートで、無効となったプロトコルです。非推奨のプロトコルになるので、有効にする場合はセキュリティ面でリスクがあることを理解の上、有効化してください。
なお、今現在、私にとってもっと深刻なことが起きた。Windows 10を「回復ドライブ」で回復させたら消してはいけないパーティションも削除され、少なくとも一か月半のデータを喪失した。パーティション切ってるシステムドライブだけリセットされるだろうと高を括っていたらまさかの結果だった。アドレナリンが出て臨戦態勢になってるのがわかる。
「本当に頭いい人はわかりやすい説明ができるはずだ」という言葉が大嫌いだ
「本当に頭いい人はわかりやすい説明ができるはずだ」という言葉はバカが「わしらにわからんような話をする奴はバカだ。わかるように話せ」という傲慢なニュアンスで使うから好きでないが、そもそも論理的にも正しくないように思う。
実際には頭いいけれど説明がわかりにくい人もいるだろうし、そういう風に話したくない人もいるだろう。
そもそもバカにでもわかるように説明するには工夫が必要でエネルギーがかかる。その上何かを曲げて説明することになるので厳密性が失われる*1。そして得られるものは少ない。合理的な人はそんななんの特にもならなそうなことに労力を割きたくないし、誠実な人や神経質な人は不正確な説明をするのに抵抗を感じるだろう。
だがとりあえず、「本当に頭いい人はわかりやすい説明ができるはずだ」が論理的におかしい*2ように感じることに的を絞って、命題・対偶・逆・裏にして並べることであぶりだせるかもしれないと思ったのでやってみた。
命題・対偶
命題「頭いい人なら分かりやすい説明ができる」
対偶「わかりやすい説明ができないなら頭がいい人ではない」
裏・逆（命題・対偶とは実は直接の論理関係はない）
裏「頭いい人でないならば分かりやすい説明ができない」
逆「わかりやすい説明ができるなら頭がいい人だ」
このケースでは命題の裏・逆である「頭いい人でないならば分かりやすい説明ができない」「わかりやすい説明ができるなら頭がいい人だ」のように思える。
そしてそれならその反対である「頭いい人なら分かりやすい説明ができる」「わかりやすい説明ができないなら頭がいい人ではない」は真とは言えないということができる。
と、このように並べてみたのだが、そもそも命題・対偶と裏・逆は直接の論理関係はないから、片方が偽だからといってもう片方が真ということはできないし、逆も然り。だから命題・対偶・裏・逆を導いて片側を真だ偽だと断じたところでもう片方の真偽を論理的に導けるわけでなく、あまり意味はなかったのだった。
そもそもAならBであると言えるためにはAとBが親子関係（必ず含まれる）になっていなければいけない*3。
「頭いい人」の親集合が「わかりやすい説明ができる人」ではないし、「わかりやすい説明ができる人」の親集合が「頭いい人」というわけでもない。
「頭いい人」と「わかりやすい説明ができる人」は対等の関係、ベン図でよく見る重なる部分がある2つの丸だろう。
ただ全く関係がないわけではないから重なる部分が大きいだけで、頭がいいのに説明が下手な人も、頭がよくないのに説明が上手な人もいるというだけの話だ。
つまり、そもこれは「AならばB」という論理で扱われることが不適切な話なのだ。
こんな理屈をこねなくても、頭いい人でも簡単に説明するのが難しいことがあるのは、法律や情報科学のような「人間が勝手に定めたルール」は非直感的で非統一的で簡単に説明するのが事実上不可能なものが多いことからもわかる。
ワイモバイルからもらえるキャリアメールだけを受信する設定をしてた
ワイモバイル(Yahooモバイル、Yモバイル、Y!mobile)と契約して一つ大きな誤算があったのは、キャリアメール*1が使い物にならなかったことだ。
キャリアメールアドレスは@yahoo.ne.jpなのだが、Yahooのアカウントと連携すると、本来あるYahooメール（@yahoo.co.jp）と統合されて、未読メールが1万件越えというひどい状態になる。
Yahoo!様はキャリアメールだけを受信し表示するというオプションを用意してくれていないのだ！
それでも何とかキャリアメールだけを分けて受信したかったので頑張って何とかした。
作戦は、Gmailアカウントを2つ新しく取得して、片方にYahooの全てのメールを読み込ませた後、キャリアメールだけをもう片方のGmailに転送するフィルタを作り、モバイル端末のメールソフトには転送先のGmailアカウントを受信メールサーバとして設定するというものだ。
つまりYahoo→Gmail1→Gmail2 とメールをリレーさせる作戦だ。
以下、設定のログ
ちなみに私はモバイル端末はiPhoneを使っている。送信メールサーバはキャリアメールのを設定して@yahoo.ne.jpからできるようにした。
- 適当なGmailアカウント1とアカウント2を取得する
- Gmail1の「設定＞アカウントとインポート＞他のアカウントのメールを確認」にワイモバイルのメールのpopサーバを設定する
- 「設定＞フィルタとブロック中のアドレス」から「新しいフィルタを作成」
- 条件 To に
ユーザ@yahoo.ne.jpを設定。ちゃんとキャリアメール（@yahoo.ne.jp）だけより分けられているのを確認したら条件を作成 - この検索条件に一致するメールが届いたとき: 「次のアドレスに転送する:」にチェックを入れて、Gmailアカウント2を指定してフィルタ作成
- 条件 To に
- Gmail2にキャリアメールのみが転送されていることを確認する。
- モバイル端末（iPhone）の「設定＞パスワードとアカウント」から既存のY!mobileメールのアカウントを停止。新規にアカウントを追加。
これで何とか目的の、キャリアメールを選り分けて受信ことには成功したのだが、かなりラグが生じることになり、リアルタイムのやり取りには向かないようになってしまった。
その後、iPhoneを使ってるのならiCloudメールが取得できることに気付いたので、この設定を封印し、iCloudメールをキャリアメール代わりに使うようにした。
iCloudメールの、キャリアメール代わりの運用（エイリアスを使用した使い分け）
iCloudメールはアドレスのエイリアスを3つまで作れて、アドレスを教えたくないけど教えざるを得ない相手に一時的に連絡先を教えるときとかに便利だ。
私は本当のiCloudメールアドレスを秘匿しておいて、以下のようなエイリアスを使い分けている。たかったが、後述の理由でエイリアスを2つまでに抑える方針にしている。
- 教えたくない相手用（このアドレスは不定期に破棄する。）
- 一期一会と企業案内用（氏名を変更して匿名にしている）
- リアル用（このアドレスはあまり変更したくない）
その後、エイリアスは削除してから7日間は新しく作り直すことができないことが判明したので、アドレスのスムーズな変更（しているように見せかける）のために、エイリアスに一つ余裕を持たせておかなければいけない。だからエイリアスを2つだけ運用するようにした。
- 教えたくない相手用（リアル氏名寄りのアドレス）
- 匿名アカウント用
の2つだけを作って、何か問題が生じたら破棄して空いているエイリアスで作り直す方針。
リアルはそもそもiCloudメールじゃなくて別の連絡手段を使うし、もしこっちのメールを教える場合はいつでも通じなくなる可能性がいつでもあることを前もって伝えておく。
（エイリアスを破棄して作り直すときのために他に代替連絡手段を教えていなくて連絡を取り合いたい相手や、有用な業者などをメモしておこう）
scoopの導入
環境変数 `SCOOP` と `SCOOP_GLOBAL` を設定する(インストール先をd:\scoopにする場合)
> setx SCOOP d:\scoop\%USERNAME% > setx SCOOP_GLOBAL d:\scoop\global /m
- [scoopのインストール先を変更する - Qiita ](https://qiita.com/eamat/items/c91be7a9eb71a709b32b)scoopのインストール先を変更する - Qiita
PowerShellを立ち上げインストール
iwr -useb get.scoop.sh | iex
インストールするもの
nodejsのバージョン管理はnodistにしようかと思っていたけれど、Linuxとの統一感を高めるためにnvm-windowsにした。そもそもnodistはscoopにないので入れるならghqなどで管理することになる。Mac、Linux、Windows(WSL無し環境)でNode.jsバージョン切り替え方法を統一したい – One IT Thing
nodejs
scoop install nodejs
Fluent Terminalの導入
scoop install 7zip git
(管理者権限で) scoop bucket add nonportable scoop install fluent-terminal-np
GitHub - felixse/FluentTerminal: A Terminal Emulator based on UWP and web technologies.
wsltty(wsl用mintty)
wslttyがなんかバッチファイルの場所などをハードコーディングしているらしくて、そのまま
scoop install wsltty
すると大量にエラーが発生するから事前準備が必要。
scoopインストール先の buckets/extras/bucket/wsltty.json ファイルを以下の内容で作成。
{ "version": "3.1.0.2", "description": "Mintty as a terminal for WSL (Windows Subsystem for Linux).", "homepage": "https://github.com/mintty/wsltty", "license": "GPL-3.0-or-later", "architecture": { "64bit": { "url": "https://github.com/mintty/wsltty/releases/download/3.1.0.2/wsltty-3.1.0.2-install-i686.exe#/dl.7z", "hash": "c0726db869c17c49361d143d6ff1566754ef7d45faa3d784cd7f7523958fd1e7" }, "32bit": { "url": "https://github.com/mintty/wsltty/releases/download/3.1.0.2/wsltty-3.1.0.2-install-x86_64.exe#/dl.7z", "hash": "bedc400ec9ca86aed1b051f84a30e6158f02b6e0cd1c3b1d4eef3d2e4f7ce2a4" } }, "extract_to": "installer", "installer": { "script": [ "Push-Location \"$dir\\installer\"", "& .\\install.bat \"$dir\" \"$dir\\config\"", "Pop-Location" ] }, "post_install": "Remove-Item -LiteralPath \"$dir\\installer\" -Force -Recurse", "uninstaller": { "script": [ "$env:installdir = $dir", "Push-Location \"$dir\"", "& .\\uninstall.bat", "Pop-Location" ] }, "checkver": "github", "autoupdate": { "architecture": { "32bit": { "url": "https://github.com/mintty/wsltty/releases/download/$version/wsltty-$version-install-i686.exe#/dl.7z" }, "64bit": { "url": "https://github.com/mintty/wsltty/releases/download/$version/wsltty-$version-install-x86_64.exe#/dl.7z" } } } }
それから
scoop bucket add extras scoop install wsltty
