Archive for October, 2021

(2021/11/5 4:10) その後いろいろあり、QOwnNotesは作者共々クソだという結論に達し※、使うどころか画面を見るだけでもイライラするのでアンインストールして、とりあえずZettlrに戻った。それで使いにくいことがあれば、何とかすることにした。

※実際に使ったりフォーラムをのぞいてみて、自分で確認されたい。

やっぱり、舌の根は永遠に乾かないようだ。(そもそも、舌の根が乾いた時は死んでいるのではないか?)

であるので、以下のほとんどは「古い情報」である。


先日は、MDの編集は(Joplinじゃなくて)Zettlrが一番いいと思ってそう書いたのだが、そのすぐあとに、「ちょっと待て」的な展開になった。

先日のリストで「最初に何か(MDは不可)開かないと起動しない。」と書いて却下したQOwnNotesは、本当にそんなにしょうもないものかと疑問に思ったのだ。それに、仮に何か開かないと起動しないとしたって、機能が良ければ使えるかも知れないとも思った。

再度試したら、以前(Evernoteを止める時だったか)試した時の設定の痕跡が残っていたために、何か開かないと起動しない状態になっていることが分かった。再設定したら普通に起動した。全く失礼だった。

しかも、再度試す きっかけとなった機能紹介ページにあるように、機能や操作性がちゃんとしていて意外にいい感じだった。それでも、「完璧」とは言えないが、他に全滅なので それだっていいと思って詳しく試した。

Evernoteを止める時に試した時は、MDを使う気がなかったのとスマフォ版がないので却下したように思うが、今は状況が違って充分候補になる。

結果は、結構な当たりだった。Zettlrに完勝している訳ではないが、良い点はZettlrより多く、悪い点はZettlrより少なかった。(→ 付録を参照)

一番いいのは、ごく当たり前の話ではあるが、sym-linkに対応していることだ。これで、前回苦労して作ったけど なんか煩雑で嫌いな、MDが変更されるたびにJoplinにコピーし続ける処理が不要になる(と思った)。

一方で、Zettlrにない欠点もある。QOwnNotesはリソース(画像)の格納先にはノートのトップディレクトリの"media"というディレクトリだけしか指定できないのだ。それ以外の指定では概ね画像は出ない(フルパスとかを書けば可能らしいが、僕の用途には向かない)。

かたや、Joplinはノートを外部編集に出す時には画像ファイルをノートのトップディレクトリの"resources"に入れるので、そのままではQOwnNotesで画像が出ない。ひどいことに どちらも強情で、設定でディレクトリを変えられるようにはなっていない。

改造した時(後述)に分かったが、QOwnNotesは意外にディレクトリ名をハードコードしていて、それが何箇所にもあった。機能などの出来がいい割には雑なところがあって、どこの人かは分からないがUS的な雰囲気を感じた。

そのせいか、フォーラムでの問い合わせに作者は「変更はできない」と平然と書いていて(参照不明)、なかなか「ん?」だった。

一方、Joplinはディレクトリ名を定数にしていたので、こういうところは抜かりないものだと感心したものの、変更できないようにする考えが理解できなかった。まあ、変えると全部のノートに影響してシステムが崩壊してしまいかねないのは分かるから、仕方ない。

それで、仕方なく「何とか」しようと思った。これはZettlrの時に比べれば簡単で(とその時は思った)、Joplinの出すノート(作業用ノート)中の画像指定タグ中の画像のディレクトリ("resources")を"media"に置換してQOwnNotesに出せばいい。

なお、画像ファイル本体はresourcesにあるので、resourcesをmediaにsym-linkしておく。

早速実装しようとして、気付いた。編集が終わったノートをJoplinに戻す時には、逆に"media"を"resources"に変換しなくてはならないが(そうしないとJoplinで画像が出ない)、それは そんなに簡単なことではない。というのは、いつQOwnNotesで編集を終えるか分からないからだ。※ Zettlrの時同様、Joplinが作業用ノートを削除したことを契機にできるが、削除されたファイルの中身は置換できないので、やっぱり、Zettlrの時同様に、ファイルの変更を監視して逐次Joplinにコピーすることになって、何も簡単ではない。そんなはずではなかったが・・・

※もちろん自分(僕)は分かるので、そういう(手動の)操作を追加すればいいが、必ず忘れるし面倒なので、そういうことは避ける方針だ。これは、PCでUSBメモリを抜く時にアンマウント操作をすべきかどうかの話*に似ている。

*不要という人も多いが、僕はOSの仕組み上、必要だと思う。例えば、OSは、メモリがいつ抜かれるか分からないではないか。それに備えて常に安全策を取っているOSがあるようだが、それは何か違うし、それだって完全に安全ではない。そういうOSでは書き込み中に抜いてもいいのだろうか?

本当に「何もせずに抜いていい」と言うなら、USBの端子に「抜かれつつある状態」を検出する仕組み、または、処理中は抜けないようにロックする仕組みが必要だ。

しかし、一晩頭を冷やして考えて、(他の案もあったものの、)QOwnNotesかJoplinを改造して、QOwnNotesが"resources"を認識するようにするか、Joplinが作業用ノートに"media"で出すようにすれば、万事丸く収まる気がした。

早速QOwnNotesを改造してみたら、うまくできた。ただ、オリジナルのQOwnNotesが更新されるたびに改造し直す必要があるので面倒だ(作者にフィードバックしてオリジナルに入れてもらえばいいが、結構なパワーが要る)。※

QOwnNotesにはスクリプティングという機能(JavaScriptらしい)があり、それを使えば改造しなくても実現できるかもしれないが、なかなかハードルが高いので保留にした。

※と書いたら、さっき更新の通知が来たwww (18:00)

更新のたびに改造するのはJoplinでも同様だが、僕はJoplinに これ以上の改良は期待しておらず、激遅とメモリの馬鹿食いが解消されない限りMDの編集には使わないので、仮に今後更新しなくても大きな問題はないと考え、Joplinも改造してみた。こっちはGUI版とコマンドライン版があって全部は確認できていないが、おそらくうまく行ったと思う。

JoplinはJavaScript(正確にはTypeScript?)で書かれているので、コンパイルが不要なのが楽だった。 (← TypeScriptからJSへのコンパイルは要る。これが長くて面倒・・・) でも、nodeの更新が必要なのに気付かず、ちょっと手こずった。

それから、Joplinにはプラグインの機能があるので、それを作れば改造しなくても実現できるのかも知れないが、QOwnNotesのスクリプティングと同様にハードルが高い。

Joplinは以下のように改造した。

  • ノートを外部編集設定した時
    • 作業用ノート中の画像指定のディレクトリの"resources"を"media"に置換する。
    • それがファイルに書き出される。
      • それがQOwnNotesに読み込まれる。
  • ノートの外部編集設定を解除した時
    • ファイルから読み込んだ作業用ノート(QOwnNotesが更新した(かも知れない)もの)中の画像指定のディレクトリの"media"を"resources"に置換する。
      • そのあとで、何事もなかったようにJoplinの内部パスに変換される。

なお、外部編集設定している間もJoplinはノートが更新されるたびに表示を更新するので、その時は画像が出なくなる。読み込まれるたびに変換すればいいのだろうが、無駄な処理だし面倒なのでやっていない。 (← その後、更新されても ちゃんと画像が出ることが分かった。それが下に書いたように正しい動作で、出なかったのはQOwnNotesの版(改造版かどうか)と合ってなかったからかも知れない。)

良く考えると、読み込まれるたびに上の変換が行われるはずなので、外部編集設定を解除するまでは、少し動作が違うのかも知れない。まあ、それほど大きな問題ではない。

あとは、改造版Joplinを「ちゃんと」使えるようにすればいいのだが、改造したものは「開発版」と出ていて設定なども本物とは別で、その直し方(書いてない・・・)を調べようとするところで力尽きたw

→ JSとTSの違い(あと、昨日はJSを直して居たが、それはTSから生成されるため、危うく消滅するところだった)、その他諸々に戸惑いながらも どうにかできた。改造版Joplin (GUI版)とオリジナル版QOwnNotesで連携できている。

CLI版は謎の動作(中身を表示すると、画像のディレクトリが外部編集と同じディレクトリになっている)だが、オリジナル版と同じなので良しとした。面倒なのでAppImageは作らず、npmやnodeで起動することにした。

npmとnodeとelectronの違いが分からないが、興味ないので放置する。

あとはQOwnNotesでの画像の追加や新規ノート作成に対応などが残って居るが、おいおい やりたい。 (これも疲れそうだ) (11/1 13:33)

 

それから、(これが最初だったのだが)上の処理の他に、QOwnNotesの動作を改善し、使いやすくするための処理をJoplin→QOwnNotesのコネクタに入れた。

  • QOwnNotesはノートのタイトルをファイル名から取るが、Joplinのノートのファイル名はIDなので、ノートを表示させないとタイトルが分からなくて不便。
    • それを解消するため、Joplinが外部編集設定した時に、作業用ノートのタイトル(Joplinでは最初の行に書かれている)を短縮してファイル名に入れるようにした。
    • 重複を防ぐため、元のIDも付けるようにした。
  • QOwnNotesは画像タグのタイトル(またはキャプション)が空だと画像を表示しない。
    • それを解消するため、Joplinが外部編集設定した時に、作業用ノート中にタイトルが空の画像タグを見付けたら、ファイル名をタイトルに入れるようにした。
    • MDでは画像のタイトルを見ることはまずないし、空のものにファイル名を付けるのに特段の問題はなさそうだ。
    • ※ノートから画像を抽出する部分のソースを見ると、タイトルが空でも問題ないはずなのだが そうでないので、別のところで落としているようだ。

 

と、最初は「簡単だ!」と思ったけど実はそうでもなかったという、いつものパターンである。(Joplinの改造を仕上げる件が残って居るものの、)今は、以下のように普通にMD(画像も)が表示でき、快適に編集できている。

QOwnNotesをJoplinの外部エディタにして、ノートを編集できるようにした。

 

最後にもう一回言いたいのは、ZettlrでもQOwnNotesでも どちらもでいいけど、Joplinのエディタを使っていた時のイライラから解放され、まさにサクサクと(それが普通なんだけど)文章が書けるようになって(Joplinも最初はそうだったはずだが、いつの間にか肥大化・肥満化・劣化してしまったようだ・・・)、うれしい限りだ。

 

付録: ZettlrとQOwnNotesの長所と短所

主に相互の比較の観点で書いた。また、基準はJoplinのエディタ(機能としては かなり良いほう)である。なお、太字は僕が重視した(「これはちょっと」、「これはいい」と思った)点である。

Zettlrの長所・短所

  • 長所
    • 他のエディタよりは ちゃんと使える。
    • 全ノートに対する検索ができる。
    • ノートの編集ペーンはプレビュー兼用だけど見やすい。
  • 短所
    • 検索で前候補に行けない。 → その後、Shift+Enterで行けることが分かった。 (11/5 5:53)
    • sym-linkで誤動作する。 → コネクタで対応した。 → 最新版(2.0.2)では直っていそうな感じ。ただし、相変わらずsym-linkのファイルは開けない。 (11/5 5:53)
    • MDのタグの動作が変・変なものに変えてしまう場合がある。例: コードブロック, 横線 → Auto completeを調整すれば大丈夫そうな感じ。 (11/5 5:53)

      • それをコピー・ペーストしても、ちゃんと働かないことがある。補完の影響?
    • ()や"などの補完が余計なことが多いうえにoffにできず、面倒。 → 設定があった(最新版で増えた?)。それ以外もAuto completeを調整すれば大丈夫かも。 (11/5 5:53)
    • 編集中に表示位置がジャンプすることがある(Joplinよりはずっと少ない)。
      • プレビューが別でないので、ジャンプは仕方ない?
      • 表示はジャンプするが、カーソル位置は動かないので まだ良い。 (11/5 5:53)
    • 選択したブロックを箇条書き・番号リストにすることができない。 → 選択して右クリック → "Insert numbered/unordered list"でできる。が、箇条書きは頭の文字が違う(そのうち直る?)。 (11/5 5:53)

      • 番号リストのリナンバーもできない。 (できるものは見たことない)
    • 書式設定の ショートカット・ボタンが少ない。
    • 細かいカスタマイズができない。 → CSSの調整である程度できる? (11/5 5:53)
    • 日時の挿入ができない。 → スニペットで代用できる。(11/5 5:53)
    • 日本語処理が今ひとつ。
    • 左サイドバーの機能が貧弱。
    • Joplinのタグに相当するものがない。
    • Joplinとタイトルの指定方法が異なる。
    • テーマの色の趣味が悪いうえに調整できない。→ CSSで調整できる。 (11/5 5:53)
      • テーマでフォントも決まってしまうので不便。

QOwnNotesの長所・短所

  • 長所
    • 他のエディタより ちゃんと使える。
    • 使用メモリ量が少ない。: Zettlrの約1/4。
      • 例: 4ノートを開いている場合、アイドル時約140MB
        • この少なさは何かの間違いではないかと思って調べ直すのだが、合っている。
    • 編集中に位置がジャンプしない。
      • ただし、プレビューペーンは頻繁にジャンプする(それでも、Joplinと違って ちゃんと戻る)が、エディタは動かない。
    • 全ノートに対する検索ができる。
    • 細かいカスタマイズが結構できる。
      • できないことも結構ある。
    • 日時の挿入ができる。
      • フォーマットが変更できる。
    • ノート一覧が縦なので、ノートが多くなっても見やすい。
    • 高速
      • ノートの切り替え(読み込み)がJoplinよりずっと速い。
    • 文字列を選択してネットで検索できる。
      • これが欲しかった!!
    • Joplinのタグに相当するものがある。
    • ノートの暗号化が可能
      • 実際に使うかは不明。
    • スクリプティング機能がある。
      • 実際に使うかは不明。
    • コネクタでノートを常時コピーしないので、Joplinでの変更が検出できる。
  • 短所
    • 画像の保存ディレクトリとタグのディレクトリが"media"で固定。対応が必要。 → Joplinを改造し、外部編集時のディレクトリを"media"にして対応した。 (11/3 13:36)
      • 本文に記載のとおり。
    • 選択したブロックを箇条書き・番号リストにすることができない。 ← スクリプトでできることが分かった。すごい。 (11/2 6:21)
      • → スクリプト"List maker"でできる。 (11/2 6:21)
      • 番号リストのリナンバーもできない。 (できるものは見たことない)
        • → スクリプト"Fix list numbers"でできる。 (11/2 6:21)
    • 書式設定のボタンが少ない。
    • MDの解釈・実装のJoplinとの差
      • 画像タグのタイトル([])が空だと表示されない。 → コネクタで対応した。: 修正する(ファイル名を付ける)ようにした。
      • HTML要素(例: "<s>")をコードブロックに入れても無効化できない。 → &xxx;を使うしかない? なぜか、今試したら問題ない。他のアプリとの混同や勘違いだった? (11/2 8:44)

        • あとで問題になりそうではある。
      • 画像タグの前に空行がないと、プレビューがおかしくなる。
        • 画像の前に縦の空白が入る。
      • 単一の改行は無視されて繋がってしまう。空行を入れないと、期待する結果にならない。
        • MD本来の動作なので、仕方ない。
        • こいういうのが嫌で却下したMDエディタがあったが、QOwnNotesは それを補うほどのメリットがある。
        • ただ、それと違うのは、勝手にノートを変更(「修正」)しないことだ。これは重要だ。
    • 検索結果のハイライトが消せない。 → 対処してもらって解決した。 (11/3 13:36) → が、実際には、どうしようもない場当たり的な修正だったし、作者自身が作ったものの仕様を覚えてなくて、こっちが混乱させられたり(そもそも、ハイライトが消えないのが仕様だったのを、僕に指摘されて場当たり的に消したものだから、整合性が取れなくなった)と、クソさが露呈し、それで使うのを止めた。 (11/5 20:40)

      • 検索文字列を消せばハイライトも消えるが、位置がリセットされてしまう。
    • 日本語処理が今ひとつ。
      • 直接関係ないが、日本語入力(Fcitx+Mozc)の未確定入力の下線が出ないのがちょっと辛い・・・ Fcitx側で調整できるのだろうか? → いろいろ調べたところ、Qt5の問題のようだ。ほとんどのアプリで下線が出ない。 (11/1 17:01) → QOwnNotesの問題ではなく、fcitx-qt5の問題だった。自分で対処した。 (11/3 13:36)
        • ただ、LibreOffice CalcとImpressでは出るのが謎。使い方があるのだろうか?
    • 画像がある場合、プレビューの縦の余白が広過ぎることがある。
      • 画像タグの書き方によるようで、次を空行にすれば直ることが分かった。
    • ノートにタイトルが指定できない。: ファイル名で見るしかない。 → コネクタで対応した。: ファイル名にタイトルを付けるようにした。
    • プレビューペーンが最後まで見えない(ことがある)。
      • コードブロックの開きと閉じの対応(インデント)が悪かったためだった。
    • 書式付き文字をコピーして、他のアプリでペーストすると、書式の文字列も貼り付けられてしまうことがある。: 再現せず。
      • 別のアプリ(ReText)だったか?
  • QOwnNotes

    QOwnNotes

    Open source markdown note-taking for Linux, macOS …

  • Overview

    Overview

    Open source markdown note taking for Linux, macOS …

  •  0
  •  0

Joplin(特にエディタ)がクソで使い物にならなくなったので※、他を探してみたのだが(試したものを付録に書いた)、結局、Zettlrしか残らなかった。エディタの機能ではJoplinは足りているのだが、遅かったり表示がジャンプしたりと邪魔されて普通に文章が書けないという点で、使うことができない。

※想像して欲しい。1文字打つ・消すたびに5秒くらい待たされるので、記憶と予想で新しいカーソル位置を想定して作業する苦しさを。30年前のviだって、そんなことはなかったよ。もちろん、何か大きなことをすると(いつ起こるかは不明)いきなりカーソルが行方不明になって、文章を書くレベルじゃねえ!

前回候補に挙がったTriliumは、(いろいろな問題はあるけど一番大きいのは、)内部的にMDでない(HTMLのようだ)※せいかJoplinのノートを開くと書式が変わってしまう。Triliumを使うために全部のノートを見て修正するなんてやってられないので、やっぱり使いものにならない。

※どうしてそうしたかは分からないが、推測してみると、MDよりHTMLのほうが 幅広い表現が可能なためかも知れない。が、世の中の標準に合わせずに自分だけの(詳細が不明な)仕様で通そうとしても先は ない。そういう点で、Triliumはセンスが悪い。

更に、PC(Linux)だけの話なら まだいいが、僕はスマフォ(Android)でもノートを共有して開きたい。すると、ノートの同期システムが必要になるのだが、こちらも(僕には)まともなものがなかった(例: ちゃんと同期しない、電池を食う)。また、同期するといっても、常に全部のノートをスマフォに入れておく必要はなく、見たいものだけ適宜ダウンロードすればいいのだが、そういうものは なかなかない。Dropboxは近いのだが、その上のノートをMDエディタで開いた時に画像が開けない問題があった。Dropbox対応のMDエディタなら可能かも知れないが、有料である。※

※高いものではないから、ちゃんと使えるなら買ってもいいけど、買わないと確かめられないので どうにもならない。

すると、PCとサーバとスマフォでノートを同期するという点では、Joplinは必要充分で なかなか良いことに気付いた。

なお、JoplinのAndroidアプリはLinux版と同様に重くて(EvernoteのAndroidアプリと同様) ほとんど編集はできず、表示専用と割り切っている。

そこで考えたのは、いつものように、JoplinとZettlrで「何とかする」ことだ。それぞれの得意な(「使える」)ところを使い、以下のように分業させるのだ。

JoplinとZettlrの分業

  • Joplin
    • (Linuxアプリ) ノートの管理
    • (スマフォアプリ) スマフォでのノートの表示
      • 重いので、編集は元から諦めている。
      • ノートの編集(書き込み)の代わりに、自作のメモ記録システム(BNote)を使っている。
        • 必要なら、そのメモをPCでノートに貼り込む。
    • ノートのサーバとの同期
  • Zettlr
    • ノートの編集

試しに上記の分業システム(のPoCかプロト)を昨日作り、どうにか動くようになった。以下に基本的な動作を示す。

動作

  1. Zettlrで編集したいノートに対して、Joplinで外部エディタでの編集を設定する(ノート名で右クリック → "Edit in external editor")。
    • あらかじめ、Joplinの設定の外部エディタに、JoplinとZettlrを連携させるためのコマンド(「コネクタ」?)を指定しておく。
  2. JoplinとZettlrを連携させるコマンド(zettlr.sh)は以下を実行する。
    1. 編集用にJoplinからエクスポートされたノート(「元ノート」)を作業ディレクトリにコピーする(→ 「作業ノート」)。
      • 元ノート自体をZettlrに指定してもいいのだが、Joplinの他のファイル(設定やログ)が見えるのが嫌だし、それらを誤って変更したり削除してしまうのを防ぐために こうしている。
      • また、下にも書いたが、Zettlrは単にファイル名を指定しても開けない場合があるので、(仕方なく)作業ディレクトリを作ることにした。
      • 更に、Zettlrはsym-linkは開けないようなので、(仕方なく)編集するノートを作業ディレクトリにコピーすることにした。
        • このために かなり面倒になった。。。
        • 調べたら、ワークスペースやノートのあるディレクトリにsym-linkがあると うまく動かないことがあるようで(→ 参照)、実際に この環境でもしばらく使っていたらノートが開けなくなってしまった(なぜか、Zettlrを再起動すると開ける)ので、(仕方なく)作業ディレクトリ直下からsym-linkを排除し、ノート中のリソース(画像)を抽出してJoplinのディレクトリからsym-linkして(サブディレクトリにある分には大丈夫なようだ)表示できるようにした。これで様子を見ることにした。
    2. 作業ノートを指定してZettlrを起動する。
      • あらかじめ、Zettlrに作業ディレクトリをワークスペースとして設定しておく。
        • 設定しないと、Zettlrが起動中に新たにノートを開く時にエラーで開けない場合が多い。
    3. 作業ノートの更新または元ノートが削除されるのを待つ。
      • 作業ノートの更新の場合、少し更新を「ためて」からJoplinのディレクトリにコピーする。
        • ノートを書いている時は頻繁に作業ノートのファイルが更新され、そのたびにコピーするのは無駄だし重そうなのでそうした。
        • 現状は、10回以上更新があったか、10回未満でも約20秒間更新がなかった場合にコピーするようにしている。
      • 元ノートが削除された場合(Joplinで外部エディタでの編集が解除された)、作業ノートを削除して終了する。
        • 作業ノートを元ノートにコピーしていない場合(上記の保留された更新が未反映の場合)には、エラーダイアログを出す。 → あとで手で反映させるなどが必要。
    4. 3に戻る。
  3. ノートの編集を終える時は、Joplinでノートの外部エディタでの編集の設定("Edit in external editor")を解除する。 → 元ノートが削除され、上の「元ノートが削除された場合」が実行される。

使っている時の画面を見ても、単に「2つのMDエディタが動いているだけ」だが、背後では上のような複雑な処理をしている。そのおかげで、Zettlrでノートを変更すると少し経ってJoplinの表示も更新される。

Zettlr(左)でJoplin(右)のノートを編集している様子

 

効果・良かったこと

  • 操作性: Zettlrは高速(というか、当たり前の速さ)だし、MDエディタとしての挙動も概ね一般的(Joplinに近い)なので、書く時にストレスがなさそうだ。
    • 今までのところ、機能不明・不足以外のストレスはない。
      • 他のエディタのようなプレビュー画面はない(印刷プレビューのみ)のだが、それで充分使えるところがZettlrの表示の すごい・うまいところだと思う。やたらに機能を増やさず、着実に進めている印象がいい。
    • 一方、Joplinのエディタは まさに"disturbance/distraction-ful"だ。
  • メモリ量: JoplinもZettlrも同じElectronで動いていると思われるが、Zettlrは随分まとも(というか普通)。
    • 開いているノートの数と使用メモリ量(アイドル時)の比較例
      • Joplin: 1ノート(サイズ: 約40KB): 約1.2GB
      • Zettlr: 5ノート(サイズ: 合計約1MB): 約680MB
    • Joplinはエディタの他にノート管理や同期の機能があるとは言え、メモリを食い過ぎる。多くのノートを開くと、簡単に2GBを超える。
    • Joplinのメモリは減ることがないが、Zettlrは作業状態に応じて ちゃんと減るのが いい(というか、それが普通だ!)。

処理速度もメモリ量も、同じElectronなのにZettlrは ちゃんとしているが、Joplinは全然「なってない」。Zettlrができているので、やればできるはずのことをしていない(Androidアプリも同様にひどい)。作者は、手を広げるよりも、まず こういう基本的なところを詰めるべきだと思う。

惜しいこと

  • ノートを編集するたびにJoplinで外部エディタでの編集を設定するのが面倒。
    • Joplinを終了しなければ設定は維持されるので それほど煩雑ではないが、(可能ならZettlrに組み込まれた)シンプルなメニュー的なものが欲しい。
  • JoplinとZettlrの管理情報(タイトルの設定方法やタグやノートのIDやマークダウンリンクなど)が別々なので煩雑。
    • ノートIDの統合はできないだろうから、Joplinをベースにするしかなく、必要になるたびにJoplinに戻るのが面倒そうだ。
    • 書いていて気付いたが、Zettlrで貼り込んだ画像をJoplinに戻す必要があることを忘れて居た。面倒かも知れない。。。
    • 同様に、新規ノートはZettlrでは作れない(Joplinに入れる機能がない)。: なかなか先が長そうだ・・・
  • Zettlrの編集機能が「もう一声」。
    • 総合的には、試した他よりは ずっといいのだが・・・
      • 書式設定の機能・メニューが少ない。
      • 日本語処理は特にしていないようで、日本語中の英語の単語選択(ほとんど文章全部が選択される)もスペルチェックも誤動作する(ノートのほぼ全体が真っ赤になるw)。
    • このブログ(WordPress)のエディタくらいの機能があれば言うことないが、なかなかうまく行かないものだ。
      • 何度もブログでノートを書くことを考えているのだが、エディタの機能だけで済むものでもなく、なかなかうまく行きそうにないので諦めている。
    • あと、テーマがどれもイマイチ。自分でCSSをいじれるが、もう少し普通の感覚のものを用意して欲しかった。
      • もしかすると、日本(というか、僕?)以外では、用意されたものがごく普通なのかも知れないw が、特に色遣いの趣味が悪い。明る目の緑とかキツい赤とか止めて欲しい・・・
  • "Zettlr"の綴りが いつも分からないw
    • Zettler? Zottler? Zottero? ヒ○ラー? デスラー?などと、最初の"Z"しか分からない。

メモ・残件

  • ファイル更新の検出は、inotifywaitというコマンドを使った。これをモニターモードで動かし、出力されるイベントを読み込んで処理する。
    • ファイルのコピー中などに起こったイベントを落とさないように、モニターモードで動かすことにした。
  • 連続した複数のイベントを保留してまとめる処理は、イベントの読み込み(bashのreadコマンド)にタイムアウトを指定することなどで実現した。
  • 現状では、編集中のノートごとに上のファイル更新の検出処理が起動されてイマイチなので、いつか統合したい。
    • ただ、基本的に待っているだけなので、負荷は高くない。が、無駄にプロセスが多くなって気分が悪い。
  • 上に書いたように、Zettlrで追加した画像や新規ノートをJoplinに入れる処理が必要だが、作るのは容易ではない。対応できるまでは適宜Joplinを併用するしかない。

 

付録: 試して却下したMDエディタ

以下のもの(すべてLinux版)を試したが、どれも僕には今ひとつだった。次点的なものはMark TextとAbricotineとReTextだった。

(書いたあとで再度試して分かったが、)Mark Textはキーの挙動と勝手な修正とメモリ量などを我慢すればZettlrより良さそうで、乗り換えたくなっている。が、更に少し試したら結構バグがあるようだし、ノートを勝手に修正されるのは困るので、保留した。Abricotineはメモリを食うのが惜しい。ReTextは いろいろ惜しい。いったい何を考えているのか分からない。そこを直せばいい感じだ。

  • Remarkable: パッケージ不足でインストール不可だった。
  • ReText: タブキーで箇条書きがインデントしない。
    • プレビューの画像のサイズが大きい(リサイズされない)。
    • ライブプレビューの表示位置がエディタと同期せず、不便。 (← レンダラーにWebkitを使えば同期する。)
    • 改行の解釈・処理が違うようで、改行だけで次に空行がないと、行が繋がってしまう。
    • メモリ量は少なそう。
  • Mark Text: MDを勝手に変更(修正)する。カーソルがノート内にある場合、Page Up/Down, 上下キーの動きがおかしい。
    • MDの箇条書きの子要素の前に余計な空行が入る(MDを勝手に変更する)。
      • その他も勝手にいろいろ(空行や空白など)書き換わる。「正しいMD」に修正してしまうようだ。
    • MDの空行が無視される。入れてもなくなる。
    • 細かいバグが多そう。
      • Ver. 1未満なので仕方ない? (結構時間は経っているが・・・)
    • 日本語対応は一番良い。
    • 雰囲気はZettlrに似ている。
    • メモリ量は多目だが、Joplinよりは少なそう。
  • MindForger: PPAがUbuntu 20.4 LTS(focal)に非対応でインストール不可だった。
  • Abricotine: 開くノート(ウインドウ)の数に応じてメモリがかなり増える。約340MB+200MB/ノート。
    • 複数のノートは別ウインドウ
    • 設定がファイル
    • 表示は綺麗。
    • Zettlrに近い。
    • 古い: 2015年。ただし、GitHubでのリリースは2020年。
  • Notable: ワークスペース型で、ノートのインポートが必要。
  • Haroopad: タブキーで箇条書きがインデントしない。
    • 複数のノートは別ウインドウ
    • なぜか、メニューのフォントが汚い。
    • 雰囲気が、僕が使っているエディタjEditに似ている。
    • メモリ量は少なそう。
    • 寄付の表示が消せない。 (← ボタンを押せば消える)
    • 古い: 2015年。
  • GhostWriter: 複数のノートが同時に開けない。
  • QOwnNotes: 最初に何か(MDは不可)開かないと起動しない。
  • Markdownify: ライブラリが合わないようで、起動しない。
  • Znote: Joplinで作ったMDの画像が表示できない。
  • Apostrophe: Joplinで作ったMDの画像が表示できない。
    • 機能が貧弱
    • Flatpakなので、インストール・起動・アンインストールが面倒
  • StackEditPro: サイトが開けなかった。
  •  1
  •  0

「いつもイライラしてんな?」って言われそうだけど、実際そうなので仕方ないw

Joplin(ノートアプリ)を丁度1年くらい使ったが、近頃は乗り換えたくなって居る。以下に その理由を挙げる。

  • エディタがクソで、書くことに集中できず イライラする。
    • 大きい(といっても、サイズは100KBくらい)ノートの途中に1文字でも書く(置換でも挿入でも)と、ノートの表示位置がジャンプして場所が分からなくなってしまう。しかも、その挙動が不定(ジャンプしないこともあるし、ジャンプする位置も まちまち)。
      • それで何度も、似たようなことが書いてある別の場所に書き込んでしまった。
    • 遅い。: 大きいノートを開くのも編集するのも遅い。必ず数秒は待たされる。
  • メモリを馬鹿食いする。
    • すぐに2GBを超えて(大きいノート複数開いて編集すると すぐに超える)減ることがない。
      • それでPCのメモリを圧迫するので、一日に何度も(Joplinを)再起動している。
  • サポートの姿勢が今一つ。
    • 上のような問題はフォーラムに上がっていて(、それ以前に自分で使っていれば)作者は分かっているはずなのに、「仕方ない」みたいな姿勢で放置して サーバとか新しいことをやっている。
    • 自分のやりたいものだけ直している感じ。

 

それで ちょっと思い立って今朝探してみたら、以下の(以前は見落としていた)候補が見付かった。ただ、どちらも今ひとつだ。

  • Zettlr
    • ノートを共有・同期できない(そういう機能がない)。
      • Dropboxのようなファイル共有の仕組みを使えば共有は可能だが、複数で編集した時に競合する。
        • 例: どちらかの変更が失われてしまう。
      • 僕の使い方では編集するのはPCだけなので大きな問題はないが、ちょっと怖い。
    • スマフォアプリがない。
      • 他のユーザの例を調べると、別なMDのエディタを使っているようだ。
    •  編集(フォーマット)機能が今ひとつ。
      • 例: 取り消し線がない。 ← あった。メニューになかったためサポートしていないタグ(<s>)を試したのと、インポートしたファイルでうまく動いていなかったので誤解した。
        • 標準的なMDに準拠しているためだろうが、実用性に欠けていないか? ユーザーは不満でない??
  • Trilium
    • 作者が正体不明で怪しい。
      • 名前どころか、国すら不明。
        • ドキュメントの言語やGitHubのメンバーを見ると、中国系では?
      • Webページがなく、GitHubだけ。
        • 一方、Zettlrのページは しっかりしている。
    • リリース(2017年頃)から数年経っているのに、まだV1になっていない。
    • 同期できるのはいいけど、オフラインの時にどうなるか不明。
      • サーバが独自なので、インストールが手間。
    • ノートも画像も全部DB(SQLite)に入れるのでは、あとでとんでもないことになる気がする。

今のところはZettlrしかないが、もう少し検討したり探してみたい。

その後、やっぱりJoplinが遅過ぎて使い物にならないので、試しにTriliumに いくつかのノートを移して使おうとしてみたのだが、たった1個で不完全な点(例: インポートするとフォーマットが崩れることがある)が出てきたり、そもそもセキュリティや運用上の不安(全ノートが一つのDBファイルに入っている)があるので止めた。エディタの使い勝手はJoplinより10倍くらいいいのだが、実用性・現実性(?)に欠けるので仕方ない。

一方、しっかり・堅実に作られている印象のZettlr(実際、Triliumでのフォーマット崩れは起こらない)はスマフォでうまく使えないので すぐには移れないが、何とかならないか考えるとともに、他も探したい。 (10/17 11:04)

 

PS. 勘違いした取り消し線の件でZettlrのフォーラムをちょっと見たら、別なソフトだが、MediaElch(メディア管理ソフト)同様にドイツ人らしい真面目なサポート姿勢が垣間見えて、いい感じがした。

PS2. 「Triliumが怪しい」と書いて気付いたが、僕も、以前 正体を明かさずにソフト開発の仕事を始めようとしたが、その点だけでも論外だったのを実感した。

  •  1
  •  0

数日前に、Backblaze B2(以下、B2)中の もう更新しない(であろう)データをGoole Cloud Storage (Archive) (以下、GCS)に移動する設定を追加して、10日くらい前からほぼ「定常運用」をして居る。以下のグラフを見て分かるように、操作数・データ量などや料金は落ち着いている。

保存しているだけで何もしないなら、毎日、保存データ量分の料金(現状は4円)だけが増える。更新チェック(約3回で1円, 1日1回実施している)や追加バックアップ(量と回数による。: 下を参照)をすると、その分が追加される。

今までに分かったことなどを書く。

  • データ移動(B2→GCS)関係
    • バックアップ対象設定の変更で、B2のデータがGCSに移動するか(B2の保存データ量が減るか)? → Yes.: duplicacy check -statusで各リビジョン(履歴)のデータ量が分かり、将来のprune(不要データの削除処理)で減ることが分かった。
    • 一度に大量に(全部)減らすとpruneに時間が掛かるのと、失敗した場合に大変なので2回に分けて減らすことにした。今のB2のデータ量は約270GBで、来月にもう一度、約270GB分を減らす設定をする。
      • 上を合わせるとB2の残りが0になってしまうが、集計の誤差や重複排除の影響があるため、そうはならない。ただ、残りは かなり少なくなるはずである。
  • GCSのコスト関係
    • ストレージだけの料金の見積もり: 1651円(USD 14.8)/年, 138円(USD 1.23)/月
      • データ量を1TBとし、USD 1= 112円とした。
      • 単価: 0.134円(USD 0.0012)/GB・月
    • バックアップ対象ファイルのチェック(更新チェック)の料金の概算: 3回で1円くらい。 → 約10円/月
    • バックアップ(アップロード)の料金: 推定: 約5円/回(ストレージのチェック) + 約1円/GB
    • 定期更新チェック(1回/日)と追加バックアップ分を含めた年間料金・単価の試算
      • 既存1TB, 追加バックアップなし
        • 支払い額: ストレージ: 1651円 + 更新チェック: 120(30/3*12)円= 1771円(USD 15.8)/年
        • 総合単価: 0.144円 (USD 0.00129)/GB・月
      • 既存1TB + 追加100GB/年 (1回で追加)
        • 支払い額: ストレージ: 1813円 + 更新チェック: 120円 + バックアップ: 105(5+100*1)円= 2038円(USD 18.2)/年
        • 総合単価: 0.151円 (USD 0.00135)/GB・月
      • 既存1TB + 追加100GB/年 (10回で追加)
        • 支払い額: ストレージ: 1813円 + 更新チェック: 120円 + バックアップ: 155(5*10+100)円= 2088円(USD 18.6)/年
        • 総合単価: 0.155円 (USD 0.00138)/GB・月
      • 既存1TB + 追加500GB/年 (1回で追加)
        • 支払い額: ストレージ: 2458円 + 更新チェック: 120円 + バックアップ: 505(5+500*1)円= 3083 (USD 27.5)円/年
        • 総合単価: 0.251円 (USD 0.00224)/GB・月
      • 上より、追加料金はバックアップのデータ量が効くので、回数が多過ぎなければ(例: 月に1回以下)小まめにしても良さそうだ。ただ、「100MBを10回」のように細かいものは割に合わない。例えば、1回10GB以上がいいのではないか。
    • 料金はUSD建てのため、実際の支払額は為替相場に影響される。円が大幅に安くなると困るが、さすがに2倍にはならないだろう・・・
      • Googleのレートは毎日変わっている訳ではないので、毎月更新のようだ。
  • 運用関係
    • B2→GCSの移動対象ファイル・ディレクトリの追加の仕方: 以下のようにすることで、毎年GCSに移すものが増えても、バックアップ対象の設定(duplicacyではfilters)を変えなくて済むようにした。
      1. 移動対象を同じディレクトリに作成した"Archived"ディレクトリに移動する。
        • B2: パターン「Archivedという名前のディレクトリ」をバックアップ対象外にしておく。
          • パターンの例: e:(.+/)?Archived/
            • 注: 設定ファイル内での他のパターンとの順序関係で有効性が変わる。下も同じ。
        • GCS: 同Archivedをバックアップ対象にしておく。
          • パターンの例: i:(.+/)?Archived/
      2. 移動したものを書き込み不可にする。(意図せず変更しないようにするため)
      3. 元のディレクトリにArchivedからのsym-linkを作成する。
    • 数日前に、ストレージに保存されているduplicacyの設定ファイル(config)のストレージクラスをStandardにしてみた。
      • 更新チェックやバックアップのたびにストレージからダウンロードされるので、Archiveクラスだと ストレージ操作やデータ取得の単価が高く(約10倍)、わずかに料金がかさむため。
      • configのサイズはとても小さい(< 1KB)ので、Standardクラスの料金は毎月の無料枠(5GB・月)内に収まる。
      • これにより、更新チェックの料金(現状は約10円/月)が更に下がることが期待できる。
    • 問題など
      • バックアップ先がB2とGCSの2箇所になるので、リストアが面倒(どちらにあるか・どちらからリストアすべきかを考える必要がある)。
        • まずB2で試し、なかったりArchivedに入っていたらGCSからリストアする。
      • バックアップ対象設定を誤る(例: 設定が非対称)と両方にバックアップされず、いざという時にリストアできない可能性があるので、注意・確認が必要。
      • B2とGCSでバックアップのトップディレクトリが異なるので、間違えやすい。
      • バックアップ(HDD)を整理しようとして本物を削除してしまい、B2のバックアップからリストアして復旧できた。
  •  0
  •  0

YouTubeを聴きながらツイートしていたが、量が多くなったので ここにまとめたい。当初は全部の日・演奏(3日, 12人)をまとめて書こうと思って居たが、1日分(約4時間だけでも結構疲れて いつ聴き終わるか分からないので、各日ごとに分ける。

参照: コンクールのトップページ, Wikipedia

各演奏の感想・印象

  • 本選1日目
    1. Pacholec (ポーランド, 第1番, スタインウェイ)
      • 僕はなぜか、曲を第2番と勘違いした(次の人の途中でコンクールのプログラムを見るまで気付かなかった)。間違える訳はないのだが、酔っていたせいか?
        • ただ、事前に1番の予感がしていたので、それは当たった。が、外れたと勘違いしたw
      • 第1楽章: 悪くない。が、パワーが足りないところがある気がする。迫力がもう少し欲しい。音は綺麗だ。オケ(テンポ)は少し遅い。
        • なぜかスタインウェイらしくない音だった。柔らか過ぎる?
      • 第2楽章: 綺麗ではあるが、今ひとつな感じ。音が滑らかでなく深みが足りない。
      • 第3楽章: 悪くない。こういうのが得意なのかも。ただ、音を切り気味で滑らかさが足りないところはある。
    2. Rao (中国, 第1番, スタインウェイ)
      • 第1楽章: テンポは丁度いいが、ピアノの出だしがちょっと大げさかな。一生懸命弾いている感じは するが、ちょっと違う感じ。余裕がないって感じか。
      • 第2楽章: 音が余り綺麗でなく、滑かさも足りない箇所がある。
        • スタインウェイは調子が出て来たのか、最初より少し音が良くなった気がする。弾き方の違い?
      • 第3楽章: 最後の速い部分は滑らかだったので、ちゃんと滑らかに弾けるのだ。だから、第2楽章などは ああいう表現だったのか。
    3. 反田 (日本, 第1番, スタインウェイ) → 2位
      • 以前聴いたラフマニノフのピアノ協奏曲(第2番(2016), 第3番(2019))は どちらも今ひとつだったが、今回は悪くなかった。彼(and/or 僕)と曲との相性か、彼(and/or 僕)の進化か。
        • 第3番はこの演奏を聴く数時間前に聴いたが、気の抜けたピアノで、最初の十数秒で聴く気が失せた。遅いテンポだけの問題ではないと思う。
      • 第1楽章: 気のせいか、イントロは今までで一番いい。オケも乗ってきた?
        • ピアノの出だしは許せる。ちょっと硬いところはあるが、今までの人よりはいい感じだ。
        • これは悪くない。乗れる。彼はショパンが向いているのかも知れない。
        • オケとの関係もあるが、ルガンスキーのちょっと甘い演奏より いいと思う。
        • 特に文句がない。今までの2人よりずっといい。上位に入っただけのことはあるようだ。
        • こっちも全力投球して疲れたw
      • 第2楽章: 結構遅いけど嫌にならないのが不思議だ。中盤の辺りは わずかに硬い感じ。
        • この辺りのパワーの入れ方がいい!
        • 最後の音の出し方も なかなかいい(もう少し弱いほうが好みだが)。
      • 第3楽章: 「もう大丈夫」って感じだった。
        • この当たりでは、スタインウェイはスタインウェイの音になっている。
        • 気持ち良く弾けたようだ。こっちも気持ち良かった。
      • ただ、乗れたけど、個性が薄かった気がする。それで違和感なく聴けたのでは? そして、僕が「いい」と思う演奏とコンクールで上位に入る演奏は別なので、(審査基準などは知らないが、)そこが1位になれなかった、かつ、単独2位でなかったポイントかも。
        • 優勝した人はどうなのか 楽しみではあるが、何となく気に入らない気がする。
      • (書いたあとで) この日のYouTubeのコメントを少し見たら、ほとんど(おそらく、日本人は多くないだろう)が彼を良く評価していた(例: Thomas Nguyen: "My rough guess, Kyohei Sorita will become the winner of this year competition")。それらのコメントがリアルタイムで(次の日の演奏の前に)書かれたとしたら、彼が一番いいというのは確かだ。であれば、僕が「いい」と思ったのは さほど一般ずれしていない(→ 上位に入ってもおかしくない?)ことが分かった。
        • それにしても、ここまで沢山の好評価を得るとは、彼は余程すごいようだ。
    4. Armellini (イタリア, 第1番, Fazioli) → 5位
      • イタリア人のせいか、ピアノはFazioliになった。何となく大きい(長い)。どんな音なのか、楽しみだった。
      • 彼女の演奏している姿・表情は なかなか感情豊か(passionate?)だった。反田も結構なものだったが、やっぱりラテン系は違うのかも知れない。
      • 第1楽章: 少し(結構)遅い。このテンポは余り好きでない。
        • いかにもラテン的に流麗に弾く。硬さが ないのはいいが、切れやパワーが少し欠ける気がする。
        • 切れ込みとか鋭さが足りない。
        • この辺りの音が不明瞭なのはなぜか?
          • ただ、今聴いてみるとそうでもないので、僕の問題か。通して聴くと感じるのか。
        • Fazioliのピアノは柔らかい音で、スタインウェイのような鋭さはないようだ。特に中域が柔らかいような、こもり気味で音が通らない・オケに負ける感じ(温まっていないせいかも)。
          • あと、高音などはそれなりに出るのだが、スタインウェイのように綺麗ではない。ただ、低音は綺麗で許せる。
          • うろ覚えだけど、カワイやヤマハ、あと、ヨーロッパの有名なピアノも こんな音だったかも。
        • 演奏かピアノか、音の線が細い感じもする。そこが一番物足りない。
      • 第2楽章: 最後の音の出し方は良かった。
      • 第3楽章: なぜか豹変した。それまでは、悪くはないが今ひとつな感じだったが、曲とピアノが合ったのか。
        • この楽章は今までと全然違って、かなりいい。彼女は こういう曲が得意なのではないか? テンポの変化がいかにもラテン的だ。ここだけなら上位に行けた気がする。
        • 終盤(この辺りから)がすごく良かった! そこはすごく気に入った。全部こういう感じだと良かった。
        • Fazioliのピアノはどうも今ひとつだと思って居たが、この楽章は良かったので、演奏の問題だったのかも。
          • あるいは、弾き始めのピアノの問題?

 

雑感

  • 今は、TVじゃなくてPCで好きな時に聴ける・観られる(しかも全部!)ので便利だ。
  • 審査員に懐かしい・名前を知っている人が居た。: ネルソン・ゲルナー(以前、コンサートでラフマニノフのピアノ協奏曲を聴いた), ケビン・ケナー(昔、ショパンコンクール 1990のTV番組で観た。その時は、日本人は確か横山幸雄ともう一人、女性が居たはず( ← 高橋多佳子。他に有森博 他も居て、日本人が多かった)), ダン・タイ・ソン
    • それから、低俗な話題だが、審査員に一人綺麗な女性が居たけど名前が分からなかった。さっき調べたら、それらしい人はSa Chenだけだが、なんか雰囲気が違う。まあ、どうでもいいことだ。
  • 何度も同じような曲を聴くのは苦痛。会場で聴いている人はすごい。決勝(協奏曲)だと、1日に最大4回(全部同じ曲の場合もある)、座って聴き続けるのだ。オケや審査員はもっと大変そうだ。
    • 僕は1日分を2日に分けて聴いた。しかも間に休みの日を挟んでw
  • 当然ではあるが、指揮者・オケが各演奏者ごとに異なる演奏をしているのがすごい。
    • 飽きて惰性で演奏しちゃいそうだけど、気が抜けないだろうな・・・
  • 1日の最初の頃に弾く人は不利な気がする。2-3番目くらいが良さそう。特に、決勝などの本当に一番最初は不利だ。
    • ピアノの調子 (車みたいに暖機が要りそう)
    • 審査員の調子・乗り・レベル感の確定
    • 聴衆の乗り
    • 会場(ホール)の調子?
  • 演奏者が出る時に、みんな会場の紹介アナウンスで名前を呼ばれたらすぐに出て行こうとするけど、タイミング(そのあとで少しオケが調整しているようだ)があるらしく、係の人に止められていたのがおもしろかった。フェイント?
  • 会場は結構こじんまりとしていて、いい感じ。ステージの床の木(「本物のフローリング」?)が良かった。
  • ページにある、コンクールのシンボルのデザイン(色遣い)は いい感じ。意味は分からないがw
  • 何度も聴いて(聴かされてw)分かったが、僕がショパンのピアノ協奏曲を好きでないのは、特に第1番に関しては、イントロが大げさで古臭く感じるからだ(僕にとってはモーツァルトの同第22番と同様)。それが進むにつれて解消され、第3楽章に至っては なかなか乗れて「いい感じ」ですらあることに気付いた。
    • 第2番のイントロは出だしは静かで(でも、すぐに大げさになるが)、ピアノの入り方がかっこいいので、第1番よりは好きだ。でも、なぜか今回は(いつも?)弾く人が少なかった。
  • 多くのYouTubeのコメントの中で、うまいこと言うと思ったのは次だ。
    • Lea Meine:

Pacholec : Polish essence
Rao : Great effort
Sorita : Controlled experience
Armellini : Musical freedom
I don’t think I can rank them, but that’s how I feel about their performances.

 

※最初、"final"を「決勝」としたが、スポーツのような感じがして落ち着かなかった。それと「本選」のどちらが適切か分からないが、日本のWikipediaにならって「本選」に修正した。

  •  0
  •  0

近頃、ネットのアクセスがすごく遅い気がしていたのだが、(良くあることだが)たまたま混んでいるせいだと思って居た。しかし、今朝は どうも違うような気がしたので、スピードテストをしてみると、テストが始まるまでは すごく遅いものの、スピード自体は問題なかった。

それで、DNSが遅いのではと思って調べたら、どうやら、僕が使っているDNSサービスのQuad9(9.9.9.9)は10/16(おそらくUTC)頃から急に遅くなったようだ。 (→ 参照: "Not found"になる場合あり) 以下に、DNSPerf("Not found"になる場合あり)で調べた、Quad9と有名なCloudflare(1.1.1.1)の応答速度変化を示す。

他も見てみると、Quad9同様に近頃遅くなったものが多いので、世界的な問題なのだろうか? 何かの攻撃・活動?? まあ、そういうことは僕は どうでも良くてw、とりあえず遅いのを解消したいので、PCのDNSサーバ設定をCloudflareに変更した。当然ながら、スピードテストの開始が速くなり、他のwebの表示も気持ちいいほど速くなった。

おもしろかったのは、僕のこのブログの表示は いつも遅い(でも、下に出る表示時間はそれほど遅くない)と思って居たのだが、それも ほぼ一瞬で出るようになったことだ。「今までの遅さはなんだったんだ!」と思ったw

同様に、ネットが妙に遅く感じることがあったのは、Quad9が遅いこともあったのではないか(もちろん、ネット自体が遅いことが ほとんどだったと思う)。

その後、dnspingというプログラム(パッケージdnsdiagでインストールする)でDNSサーバの応答時間が測れることが分かって調べたら、Quad9の応答時間はCloudflareやGoogleの約2-5倍であることが分かった。なお、Cloudflareは速いが変動があり、Googleは言われるほど速くなかった。以下にいくつかの測定結果を示す。

Quad9: 平均 222ms

--- 9.9.9.9 dnsping statistics ---
4 requests transmitted, 4 responses received, 0% lost
min=187.845 ms, avg=222.095 ms, max=271.483 ms, stddev=40.576 ms

Cloudflare: 平均 118ms

--- 1.1.1.1 dnsping statistics ---
4 requests transmitted, 4 responses received, 0% lost
min=23.369 ms, avg=117.756 ms, max=172.085 ms, stddev=70.577 ms

同2回目: 平均 43ms
--- 1.1.1.1 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=23.226 ms, avg=42.777 ms, max=138.602 ms, stddev=46.946 ms

Google: 平均 132ms
--- 8.8.8.8 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=22.459 ms, avg=132.160 ms, max=232.088 ms, stddev=101.970 ms

同2回目: 平均 77ms

--- 8.8.8.8 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=22.410 ms, avg=76.629 ms, max=196.265 ms, stddev=83.767 ms

それから、Quad9はどうも駄目になっている感じの記事もあった。最初は見出しからドイツ語だと思って(本文は英語だったw)拙い翻訳版しか見ていないので詳細は不明だが、良くある資金不足だろうか。

 

そんな状況を眺めつつ考えたら、べつに外部のDNSサーバでなくてもルータのでいいような気がした。というのは、Quad9は安全面で良い(例: 危険なサイトをブロックする)から使っていたのだが、Cloudflareにはそういう機能はないので、速度以外に選ぶ理由はない。が、速度ならルータのサーバ(プロバイダのをキャッシュする)が一番速いはずだ。

なお、Quad9の危険サイトブロック機能は惜しいが、今まで働いたことがないので なくてもいい気がする。ブラウザにも、危険なサイトから保護する機能はある。

書いたあとで思い出したが、たまに、なぜかCloudflareの「ブラウザをチェックしています」という画面が出ていたが、Cloudflareにも似たような機能があって、それだったのか。ということは、全然気付いて居なかったけどQuad9が使われていなかった(ダウンとみなされてCloudflareに切り替わって居た)ことが多そうだ。謎だ・・・

とすれば、Cloudflareでも ある程度は安全性の向上が期待できそうだ。ただ、上の変な画面が出る(実はこれ、最近まで危険なサイトかと思って閉じていたよwww)。 ← 調べたら、これはCloudflareのDNSでなく、CDNの機能のようなので、やっぱり、CloudflareのDNSにするメリットは(僕には)余りない。

測ってみたら、以下のように、平均1.3msと爆速だった(キャッシュされたサイトに限る)。

--- 192.168.0.1 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=1.212 ms, avg=1.273 ms, max=1.329 ms, stddev=0.044 ms

キャッシュされていないサイトはプロバイダのサーバが参照されるが、近いせいもあってCloudflareなどと遜色なかった。以下にdnspingの結果を示す。

プロバイダ(DTI): 平均 61ms

--- 2404:1a8:7f01:b::3 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=22.127 ms, avg=61.362 ms, max=209.331 ms, stddev=82.741 ms

同2回目: 平均 52ms

--- 2404:1a8:7f01:b::3 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=21.448 ms, avg=52.380 ms, max=191.389 ms, stddev=68.169 ms

あと、Cloudflareがうたうメリットの一つにアクセスが記録されないからプライバシー面で良いことがあるが、プロバイダはDNSだけでなく アクセス履歴はなんでも記録できるから、DNSアクセスだけ記録しないことにメリットはないと考えた。

それで、PCのDNS設定をルータに変えた。気のせいか、このブログの表示が更に速くなった気がする^^

なお、ルータは代替DNSサービスやv6のDNSサービスを持たないので、代替サーバ※はCloudflareにした。

※ PS2に書いたが、上(NetworkManagerの設定)は実際には「代替」サーバでなく、ルータ(またはプロバイダ)のサーバと対等な「追加」サーバとなっていた。良く調べなかったせいもあるが、この辺りは 見た目ほど単純でなく、中は すごく こんがらがっていて誤解しやすいので、今まで分からなかった。 (10/23 18:43)

僕のルータ(I/Oデータ WN-SX300GR)が残念なのは、IPoE接続(MAP-E)の時はDNSサーバを変更できないことだ。もしできれば、ルータのキャッシュにない時はCloudflareなどにアクセスできるのだが。まあ、大きな問題ではない。あと、プロバイダのDNSサーバから送られてくるのか、resolv.confにフレッツ用の設定らしきもの(例: search flets-east.jp iptvf.jp)が入ってしまうが、気にしなければ良いw

それから、スマフォ(Andorid)は簡単にはDNSサーバが変更できないため元々ルータだったので、何も変更は要らなかった。

 

結局、「ごく普通の設定」が最適だった訳で、僕が良くやる「とりあえずいじる」の「過ぎたるは−」的な失敗ではあったw

 

それにしても、数年前から「CloudflareやGoogleにするとネットが速くなる」って良く見ていたが、本当なのだろうか? (国内にもいくつかサーバがあるのだろうが、)わざわざ遠いサーバを参照しても、それに見合うとは思えない。プロバイダのDNSサーバが貧弱とか混んでいる場合の話だろうか。後者だったらネット自体も遅くなる気がする。

 

PS. 僕のPCのDNS検索が遅かった件については、DNS検索結果をPC内でキャッシュしないようにしているせいもあることに気付いた。通常はキャッシュする(DNSサーバのIPアドレスが自分のPCになる)ようだが、確かv6対応にした時に何か問題があって止めた気がする(が、詳細を思い出せない)。

→ 少し調べたら、どうやらdnsmasqをNetworkManager経由で使っていたのを2020年の年末に止めたようだ。その経緯をノートで調べたら、その時は楽天モバイル(ポケットWi-Fi)を使おうとしていて、光のプロバイダのDNSサーバの設定が競合してDNS検索が遅かった(今回のようにブラウザの表示が遅かった)ので無効にしたことが分かった。もう楽天モバイルは使わないので戻してもいいはずだ。が、ちょっと面倒だw まあ そのうちやりたい。

本文に書いたようにルータがキャッシュしているので戻すメリットは余りないが、(キャッシュで ある程度高速化できるので、遅い)Quad9が再び使えるようになることか。まあ、それにどのくらい価値があるか・・・ (そもそも、Quad9は楽天を使う時に始めたので、特に必要はない。)

(15:40) とりあえずやってみたら、またハマったw

DNSキャッシュとして最初から使われていたのはdnsmasqでなく、systemd-resolvedだった。どうも設定ファイルにdnsmasqの痕跡がなくておかしいと思った。dnsmasqは動いたのだが(これも分かりにくいことがあって、ちょっと苦労した)、元々のものがいいのでsystemd-resolvedに戻そうとしたら、DNSが参照できなくなって苦労した。

こうなるとネットの検索すらできないので、難儀した。それで一時的にdnsmasqを有効にした。

結局、ここでも楽天のための設定変更が悪かった。/etc/systemd/resolved.confで DNSStubListener=no にしていたために、プログラムがsystemd-resolvedでDNS検索しても応答がなかった。

修正したら うまく行き、キャッシュされたホストについては概ね0.5ms以内に応答が得られるようになったので満足した。(というか、単に元に戻しただけなのだがwww)

なお、DNSサーバはプロバイダのものにした(ルータから渡される情報をそのまま使うことにして、何も設定していない。 → この場合、v6のサーバが使われるようだ)。

PS2. 今調べたら、Quad9の速度が回復しているようだ。とすれば、上に書いたローカルなDNSキャッシュ機能を使えば、速度低下を起こさずに使えそうだ。そうする意味は、気休め程度にQuad9による安全性が期待できるだけだが、どうしたものか。 (と、振り出しの近くに戻る?w)

(18:32) 使えるものは使う主義なので、結局、再びQuad9を使ってみることにした。今度はちゃんとキャッシュが効いて、最初の検索以外は遅くない。もしまた遅くなったら戻せば良いのだ(でも、その時は きっと忘れていることだろうwww)。まあ、「懲りない奴」ってことで・・・

(10/22 15:50) やっぱりQuad9は遅い(定常状態で遅い)。いくらキャッシュしても、ヒット率が低い(例: 24%)ので、全体的な速度は低下する。特に、ブラウザで最初にページを開く時は(キャッシュがヒットせずに)遅くてイライラするので止めて、プロバイダのサーバにした。大体Quad9の10倍速く、再び高速・快適になった。

PS2. 僕のPCのDNS検索が遅かった件について、更に別な関連することが見付かった。ブラウザ(Firefox)の設定でDNS over HTTPSをQuad9に設定していた。そのため、webページの表示が遅かったのはOS(Linux)の設定とは関係だったようだ。OSの設定を変更して速くなったのは、たまたま同じ頃にQuad9が回復したせいなのだろうか。

あと、OSのDNSの設定も複雑で、NetworkManagerとsystemd-resolvedを使っている場合、DHCPで取得したDNSサーバのアドレス(= プロバイダのもの)も使われるのだが、それらと自分で追加設定したものが並列に有効で(早いもの勝ち?)、実際にどれが使われるかが不明だ(見ていると、時間が経つと変わるようだ)。

マニュアルもなかなか意味不明で、いろいろ設定しても なかなか意図したように(DHCPのDNSサーバアドレスを無視する)は動かない。試行錯誤した結果、NetworkManagerのv6の設定で"Automatic, addresses only"というモードにすると、DHCPではIPアドレスだけ設定し、DNSなどは使われず、systemd-resolvedにも送られないことが分かった。

DHCPで得られる情報のIPアドレス以外(DNS以外は不明)は不要なのかという疑問はあるものの、それで使ってみて、まだ大きな問題はない。 (10/22 12:24)

注: PSに追記したが、Quad9を使うのを止めたため、今は元の"Automatic"の設定に戻した。 (10/22 22:03)

PS3. 更に、DNS over TLSを使うのも一苦労だった。resolved.confでDNSOverTLSを設定するだけでは駄目で、DNSにサーバのIPアドレスだけでなく、"#"でホスト名を追加する必要があった(例: DNS=9.9.9.9#dns.quad9.net)。(→ 参照1, 参照2)

ちょっと凝ったことをしようとすると、なかなか大変だ。 (10/22 15:03)

注: PSに追記したが、Quad9を使うのを止めたため、今はDNS over TLSは使っていない。 (10/22 22:03)

 

(10/23 18:43 少し補足)

  •  1
  •  0

結構前からSpotifyで少し配信されて居たのを試しに聴いてがっかりしたので全然興味なかったが、今日 発売配信されたのを知って ちょっと試してみたが、やっぱり駄目だった。時間(とお金)の無駄だ。

  •  1枚目のメインのリミックスはオリジナル(1970, 2009リマスター)より音(音質, 音作り)が悪い。あと、アレンジ(ミックス)も悪い。
    • 音の悪さは2曲目の"Dig a pony"から感じた。特に、低音のドラム(バスドラ?)が潰れたような音だ。
    • 音がすっきりしていない、抜けが悪いという点で"Mono masters" (2009)に通じるものがある感じだ。
    • 3曲目の"Across the universe"もひどい音で、イントロから不自然な感じだ。それから、元々大げさな演奏なのに、コーラスが更に不自然になり、オケは更に大げさになってしまった。
    • ここまで聴いたところで嫌になって止めた。
    • 例の世襲プロデューサーのセンスが悪いのだろう。自己満足の改悪は止めて欲しい。
  • 2, 3枚目のセッションだのリハだのジャムは映画"Let it be" (1970)さながらの たるんだ演奏(感想の例: (3枚目)"Get Back - Take 8": 「以前の曲((2枚目)"Don’t Let Me Down - First Rooftop Performance")同様、気の抜けたサイダーもいいとこ・・・」)にがっかりした。(Spotifyの配信で数曲しか聴いてない)
    • がっかりするのも当然で、いい演奏なら当時出していたはずなのだ。出せないレベル(みんなが放り投げた)だったから、今まで残っていたのだ。
  • 4枚目のGlyn Johnsミックス(1969)は海賊盤で持っている(1970年版も)し、そもそも中身が余りおもしろくなかった(「オリジナルよりずっといい」とは言えない)ので、今出ても聴く気が起こらない。
  • 5枚目の"Let it be EP"は何のためにあるか不明で、やっぱり おもしろくなかったが、このセットの中では一番まともな気がする。

結局、僕にとっては、スペクターの労作であるオリジナル版(音質の点では2009リマスター)が一番いい。確かに、アレンジで やり過ぎな面もあるが、上に書いたように そのままでは どうしようもなかった素材を実にうまくまとめ上げたと思う。だから、"Let it be... naked" (2003)の音自体はシンプルでいいけど、やっぱりしっくり来ず、積極的に聴く気になれない。むしろ、-nakedが出てオリジナルの良さを再認識したくらいだ。

 

そして、なぜ、この5枚組にもなるデラックスなアルバムには「ルーフトップ・コンサート」が丸ごと入ってないのだろうか? 僕はこれが一番聴きたい。てっきり、2か3枚目がそうなんだと思って(良く確かめずに)掛けたが、違っていた。 → 映画(ドキュメンタリー)で出すからか。 ← 11/25から公開だそうだから、その前に音を出しちゃったらネタバレみたいになってしまうからか。

そして、そのあとにそのCDなどを(何種類も)売り出して、「二度おいしく」なるのを期待しているのか。もう、立派なビートルズ商法だ。

 

PS. 豆知識(というか知らなかったこと): 「リハーサル」の綴りは"rehearsal"だった。当てずっぽうで"reharsal"と打ち込んだら、スペルチェックで引っ掛かった。"hear"が入っているのは 分かるような気がするが、発音には出ないので妙な感じ。

他に、関係ないけど英単語関連で、同意・承諾(音は「コンセント」)を"concent"と打ったら違っていて、"consent"だった。前者は日本の「コンセント」なのだが、単語としてはあるものの一般的ではないようだ。これを送ったら笑われるところだったw

  •  0
  •  0

いつものように四苦八苦しつつも(そのため、気付いたら前回から10日も過ぎて居た)、昨日、Google Cloud Storage (Archive) (以下、GCS)への初期バックアップが終わった。約一週間掛かりだった。途中で欲が出て、予定していた音楽のファイル以外に古い写真や本など いろいろ追加したため、データ量は予定の2倍の約900GBになった。

というのは、あとにも書くが、滅多にアクセス・変更しないのであれば、現在使っているBackblaze B2(以下、B2)より維持費(アイドル時の料金)がずっと安く済むので、その分、多くのデータを保存できるからだ。

以下に、これまでに分かったことや印象・感想などを書く。

  • 信頼性(GCS + duplicacy): なぜか変な問題が起こったが、(おそらくの)原因が分かって再発しなくなった。
    • 現象: チャンク(ファイルを分割したファイル)が1個なくなった。 (→ その後、問題発生時には同時アップロードスレッド数分なくなることが分かった。)
      • バックアップ時にduplicacyやGCSからエラーは出ていなかった。
      • そのチャンクは確かにGCSになかった。
    • いろいろ調べて何とか復旧した。 (→ 参照)
      • 簡単だけど面倒だ。
    • ただ、今まで(ストレージがB2の場合)は起こっていなかったので、どうしてか気になった。相性問題?
      • チャンク約6万個のうちの1個で 低い確率ではあったが、「滅多に起こらない」とは言えない。
      • 現象は異なるが、サーバからB2にバックアップしたもののprune時に たまに「チャンクがない」エラーが起こっていたので、duplicacyに問題があるのかも知れない。
        • この問題は、B2のメンテ中にアップロード(バックアップ)したせいで起こっている(やっぱり、サーバからのエラーがduplicacyに伝わってない?)と想像し、定期メンテ中のアップロードを避けるようにして様子を見ている。
      • → いろいろ調べたら、データをアップロードしているPCの一時IPv6アドレス(temporary IPv6 address)の更新の影響のようだった。
        • 直接の原因は自分で変えた設定が不適切だったことだが、他のプログラムは今まで問題なく動いていたので、そればかりとは言えない。 → 詳細は下記 「一時IPv6アドレスの更新の影響について」を参照のこと
    • → 一回だけでなく再発したので、チャンクサイズをデフォルトにして試したが、効果はなかった(やはり再発した)。
      • アップロード速度が低下したが、バックアップのスレッド数を6に増やしたら、家のVDSLのアップロードの最高速度近くの32Mbps前後まで出るようになった。
    • duplicacyは、このような問題をcheckコマンドで検出できるのがいい。
      • rclone(ファイル単位でバックアップする)だったら おそらく通信エラーになると思うが、(duplicacyと同様に)エラーにならずにファイルの全部または一部がなくなったり、異常になったりする可能性もある。それは(何もしなかったら)バックアップ直後には検出できなので、リストア時に途方に暮れることになる。
        • バックアップ後にチェックするにしても、rcloneは管理情報は持っていないので、自分で、バックアップしたファイルがストレージにあるか調べる必要があり、なかなか面倒だ。まあ、rcloneをdry-runモード(あれば)で動かせば、ファイルの有無とサイズの違いは分かるだろうが、おそらくduplicacyより高く付きそうだ。あと、中身の異常までは分からない(それはduplicacyも同じ)。
    • 上の問題の他は、バックアップしたファイルの抜けや一部をリストアして中身をチェックをしたらOKだったので、(当然のことながら)信頼できそうだ。
      • こんなところで駄目だったら、世界中のユーザーが叩くに違いない。そもそも、そんなのはGoogleでない。
  • 有用性: やっぱり(僕には)バックアップは必要不可欠だった。
    • バックアップのチェック中に誤って本物のファイルに上書きしてしまい、いくつかサイズを0にしたり変な名前のファイルを作ってしまった。
      • 原因: awkの使い方の失敗: 一時ファイル名がおかしくて上書きしたようだ。
        • 変な名前は空白のあるファイル名が分割されてしまった。
    • → でも、早速GCSからリストアして復旧できたので「セーフ」だった^^
      • 手元のバックアップHDDからでも良かったが、試しにやってみた。
  • 料金: GCSとB2を併用した場合、通常(アイドル)時は現状(B2のみ)から4割(100円/月)近く安くなるはず。
    • 連日、コンソールを頻繁にチェックして、更新・集計のタイミングや内訳が分かり、ある程度、料金表に合う額が計算できるようになった。
      • 料金(Report)は1日2回以上更新される。
        • 項目によって更新時期・頻度が異なるようだ。
        • 内訳は金額(円)でしか出ない(データ量などは出ない)ので不便。
      • 操作の回数、送受信データ量などは、モニター(Monitoring)で ほぼリアルタイムに更新される。
        • ただし、全データ量とオブジェクト数が更新されるのは1日1回。
    • 事前の見積もりどおり、1TBのリストアをすると約2.1万円になるだろう。
      • 安くはないが、保険だし、データに値段はないので仕方ないだろう。
      • それに、維持のための料金を払える限り、一度に全部リストアする必要はないので、そうすれは安くなる。
    • 現状(初期バックアップ完了後, 10/14 10時頃)の使用量と料金
      • 使用日数: 約13日間 (約半分は試行錯誤)
      • 格納データ量: 約900GB
      • 削除したデータ量: 約700GB (試行錯誤のため)
      • 操作数: 約28万
        • Class A (主にWriteObject): 約26万
        • Class B (主にGetObjectMetadata, ListObjects): 約2.4万
      • GCSの送信データ量(≒ ダウンロード(リストア)データ量): 約13.5GB
      • GCSの受信データ量(≒ アップロード(バックアップ)データ量): 約1.6TB
      • 料金: 3055円: 以下に内訳
        • Class A操作(書き込み系): 1525円
        • Class B操作(読み出し系): 90円
        • データ取得: 90円
        • データ格納(us-west1): 31円
        • データの早期削除: 1161円
        • データのNW転送(ダウンロード): 158円
        • ※書き込み系操作と早期削除(どちらも試行錯誤を含む)が大半で、通常(アイドル)時はデータ格納以外は掛からない。
      • ※データ量の単位にはGiB, TiB(1024系)とGB, TB(SI系)の2系統があるが、いろいろな箇所・場合・プログラムで異なっていて換算や記載が煩雑なので、ここでは特に区別せず、大まかに"GB"などと書き、特に必要な場合だけ厳密に扱う。
    • 今後の予測・見積もり (USD 1= 112円とした)
      • GCSのアイドル時の予測額(月額): USD 約1.1 (約121円)
        • 格納データ量: 約900GB
      • B2: GCSへのデータの一部移行後の予測額(月額): USD 約0.24 (約27円)
        • 移行後のB2の格納データ量: 約48GB
          • 約412GBをGCSに移行すると見積った。
        • 従来
          • 月額: USD 約2.2 (約246円)
          • 格納データ量: 約460GB
      • 合計の予測額(月額): USD 約1.3 (約150円)
        • 現状の約246円(B2のみ)との差: 約-96円
  • duplicacyの処理・設定: 結構手間が掛かったが、いろいろ分かったことがある。
    • チャンクサイズ
      • 大きくしてみたが、重複排除効率が下がるとのことなので、大きく(平均10MB)しないほうが良かったかも知れない。
        • 効率は大差ないとは思うし、料金も大差なさそうだ。
          • データ取り出しとNW送信が高いので。
        • バックアップしてからのサイズ変更はできない。
      • → その後、上記のチャンク消失問題の原因かも知れないと思って、デフォルト(平均4MB)に戻した(実際には無関係だった)。
      • 平均チャンクサイズと実際のファイルサイズの関係
        • 全データ量: 994,100MB, ファイル数: 332176, チャンク数: 202070
          • 平均ファイルサイズ: 3.0MB
          • 平均チャンクサイズ: 4.9MB
        • → チャンク化によって、ストレージの使用効率が約1.6倍になったと思われる。ただ、ブロック数でなく実サイズで課金されるので、料金には関係しない。
      • 重複排除の効果(実際のデータ量とストレージに保存されたデータ量の関係)
        • バックアップしたデータ量: 993,910MiB, ストレージに保存されたデータ量(チャンクの総データ量): 917,429MiB
          • 差: 約75GiB, 重複排除率: 約7.7%
        • バックアップの経過(duplicacyの出力)を眺めていたら、重複排除が効いている場合もあった(例: アップロードサイズが約1割減)が、全体としては余り効いていないようだ。
      • ※ここでのデータ量はduplicacyの出す値(表示は"MB"だがMiB系のようだ)で、単位系または処理が異なるせいか、他とは一致しない。
    • フィルタ(バックアップ・除外パターン)の設定
      • 強力だが、理解不能な癖みたいなものがあって設定が面倒。
        • 予行(dry-run)機能で試せるので、何度も試しては修正した。
      • ただ、もう少し機能があるといい。
        • 例: 更新日時でバックアップ対象にするかどうか。
    • prune処理について
      • pruneを行って不要になったチャンクを削除すると使用データ量が減って料金が下がるが、GCSの使用データ量の料金は安い反面、早期削除やアクセスの料金が高い(数十倍!)ので割に合わない。使用データ量がそれほど大きくないなら、なるべくpruneしないほうが得策だと思う。
    • 日頃のバックアップの必要性のチェック方法
      • duplicacyのバックアップの予行(dry-run)機能でバックアップ(アップロード)されるファイルが表示されてファイル更新の有無が分かるので、それを定期的(1日に1回)に自動実行し、結果を見て必要だと思ったら手でバックアップすることにした。
        • このチェックにもアクセス料金が掛かるが、今まで見たところでは それほど高くないので、頻繁過ぎなければ大丈夫そうだ。
      • ちなみに、B2へのバックアップは、基本的に上と同様に(dry-runでない)バックアップを定期的(約8時間間隔)に自動実行している。
        • ただ、PCのスリープや再起動に影響されずにバックアップの間隔をなるべく一定にしたいのと、バックアップ後にチェックをするのと、バックアップ以外にprune(2種類)を別な長い間隔(約1日, 約2週間)で行うのと、バックアップが長引いた場合に同時にpruneを実行しない(その逆も)ようにしているので、実際にはちょっと複雑な自作のスクリプトを使っている。
  • その他
    • 光回線でないと(無線では)、こういうバックアップはできなかった(ちょっと する気になれない)。
      • 初期(試行も)バックアップ中のデータ量の変化(グラフの下向きがアップロード)は、以下のように、今までにない すごい傾きだ。普通の4G無線で、一週間くらい こういう通信を安定してできるだろうか?
      • GCSに初期バックアップ中の送受信データ量: 上: 受信, 下: 送信; 左上から右下へ: 日, 週, 月, 年

    • ただ、家はVDSLのためアップロード速度が遅い(最大約35Mbps)のが残念だ。
      • もしアップロードも速かったら、初期バックアップは2-3日で終わっただろう(ただ、僕の準備・処理が間に合わなかったかも)。
    • GCS(Archive)は、アクセス・書き換え・削除などせず、ただファイルを追加していくだけなら安いうえに、他のクラウド アーカイブ ストレージと違って「普通に」使える(ただし高い)から結構いいと思う。
      • 以前書いたように、WORMメディアやテープのイメージで、基本的に書き込んだら放置だけど、ちょっとお金を「はずめば」普通に使えるのがいい。面倒な解凍処理が必要で半日も待たされる他のクラウド アーカイブ ストレージにはない大きなメリットだ。
      • アクセスやNW転送(ダウンロード)の料金が下がれば言うことないが・・・
      • あと、webコンソールを もう少しまともにしてくれれば・・・
        • その他、細かいこといろいろw
      • それから、Googleらしく「止めた」とか値上げとかがないことを祈るw
    • GCS(Archive)の料金は試用クレジットの約3万円に比べて概ね安いので、最初の試行や初期バックアップには充分過ぎるくらいだ(まだ9割くらい残って居る)。やりたくないが、何回でも最初からやり直せるw

 

という訳で、目論見・見積もりが合っていれば、「保存データ量倍増、料金4割減」(→ コストパフォーマンスは3.3倍?)という うれしいことになるはずだが、果たしてどうなるか。(何もしなければ変わらないだろうが)1-2か月は頻繁に料金をチェックし、大丈夫そうならB2のデータをGCSに移行(実際には、移行するファイルをB2へのバックアップ対象から外す)したい。※

※頻繁に変更するデータをB2に残し、そうでないものをGCSに移す。

移行後はB2の月額が1ドル未満になる予定だが、それはちゃんと請求されるのか、変な心配はあるw

そして、もし移行してから失敗に気付いたとしても大丈夫だ。というのは、duplicacyは履歴を保存するので、設定した期間(僕の場合、約半年)は削除済みのデータが残って居るからだ(そのため、その間は料金は安くならない)。

いざという時に、その残って居る履歴を期限で消さないようにできるのか不明だが、まあできるだろう。少なくとも、pruneしなければ消えない。

残件としては、前回書いたように、「まっさら」な状態からのリストアの手順を検討・試行をすることと、作成または更新年が新しいのでGCSにバックアップしないようにしたファイルを、定期的に(毎年)バックアップ対象に追加する(= B2からの移行)※ことがある。

※きっと、こんな作業を自動的に行う階層的ストレージ管理ソフトはあるのだろうが、エンタープライズ用で「お高い」だろうし、使うのも面倒なんだろうと思うが、実際はどうなんだろう。実はフリーであったりするのか?

 

一時IPv6アドレスの更新の影響について

IPv6のIPアドレスは固有(一応、全世界で1個)のため、プライバシーを保護するために(IPv6 privacy extension)、有効期限付きの一時アドレスというものを短期間(Linuxでは通常は1日)で変えながら使う(そうでない設定も可能)。その期限("temp_prefered_lft" (sic))が切れると、一時アドレスが更新されて変わる。ただ、古いアドレスが即座に無効になると通信が切れて問題があるので、しばらく(Linuxでは通常は6日: 最終的な期限("temp_valid_lft")の7日-上記の1日)は使えるようになっているようだ。(ここは動作からの推測)

Linuxの一時IPv6アドレスの更新処理 (推測)

  1. システム起動時やNW IFの初期化時に、新しい一時アドレスが生成・割り当てられる。
    • そのアドレスは、preferred_lftが0になるまで新しい通信に使われる。
  2. preferred_lftが0になった(deprecated状態)は、valid_lftが0になるまで残る。
    • そのため、通信中にアドレス更新があっても、当面は問題は起こらない。
    • ただ、そのまま延々と通信を続けた場合、valid_lftが0になった時点でアドレスがなくなるので、問題が起こる。 → 通信できなくなる?

なお、preferred_lftやvalid_lftが減るのはLinuxが動いている間だけで、スリープなどで止まっている間は減らない。また、再起動でどうなるかは不明。

当初、僕は そこを理解していなかったため(一時アドレスの設定方法については情報があるが、動作や2つの期限の違いの詳細については見付からなかった)、期限が切れても無効になったアドレスが引き続き残って居るのを見て、ちゃんと動いていないと思い、temp_valid_lftとtemp_prefered_lftを同じ1日(86400秒)にしてしまった。そうすれば、実際に毎日の期限でアドレスがガラッと変わって気持ちが良かったのだが、上記のようにアドレス更新されるとそれまでのアドレスが無効になってしまっていた。

ただ、その瞬間に通信している場面が少なかったのか、あるいは、多くのプログラムが そういう通信エラーにちゃんと対処していたためか、何も問題が起こらなかったが、duplicacy+GCSだけは違っていた。たまたま見ていた時にアドレス更新が起こったら(あとでそうだったと推測した)、しばらく(30秒-1分?)アップロードが停まり(リトライしていた?)、その時にアップロードしていたと思われる(本当にそのものかの確認はできていない)チャンクが消失した。duplicacyはエラーを出していなかったので、通信できなくなる前にGCSから成功が返って来たのか、duplicacyの通信エラー検出・対策に不備がある可能性が考えられる。

この問題をduplicacyの作者に報告したほうがいいが、そもそも設定ミスに起因するのと、再現させるのに手間が掛かるし、GCSとの相性の可能性もある(B2に対しては起こったことがない)ので保留している。

これに対処するには、まずはLinuxの一時アドレスの設定を「ちゃんとする」ことで、デフォルト(temp_valid_lft= 7日, temp_prefered_lft= 1日)に戻したら問題は起こらなくなった。ただ、可能性として、以下の場合は問題が起こるのではないか(待つのに疲れたので、実際には確認していない)。

  1. 一時アドレスの更新(temp_prefered_lft)時刻の少し前にduplicacyでバックアップを開始し、
  2. temp_valid_lftの期限が過ぎてもバックアップが終わらない。

この対処(予防)のために、duplicacyでのバックアップ開始前に、一時アドレスの設定を変更して固定にし(例: use_tempaddrを1にする)、バックアップ終了後に設定を戻すことを考え、そのスクリプトを作るつもりだったのだが、その前に設定をちゃんとして試していたら(バックアップの残量が少なかったため)問題が再発することなく初期バックアップが全部終わってしまったので、スクリプトは作らず仕舞いである。

ただ、今後(忘れた頃に)問題が起こる可能性があるので、バックアップ開始前に一時アドレスの有効期限(temp_valid_lft)を調べて、途中で切れそうだったら(バックアップ量によるが、暫定で1.5日にしている)メッセージを出してエラーにするようにした。

 

こぼれ話 (Azure(日本MS)を大いにディスる)

以上の話とは全く関係ないが、Azure(日本MS)はトライアルの使用状況を聞くために電話(マジで!)を掛けてくるというアフォさ。その連絡メールは、「いつがいいか知らせろ。返事しない場合はテキトーに掛けるよ」(意訳)で、「は????」としか言いようがない。

こっちは、何もしてないのに規約違反のアクティビティを検知したとかでアカウントがロックされたままで使いようがないのに、そういうことを調べもせず ただ電話すればいいという、昭和的馬鹿営業の極み。掛かって来たらブロックするのが楽しみだ。

電話で、ロックの件やAzureが使いにくいとか言うのも可能だろうが、大抵その場の「なるほど」、「検討します」だけで何も変わらず(というのは、そういうのは向こうの期待する回答じゃないため)、こっちが対応する労力が無駄なことが分かっているのでしない。

→ と書いたら、書き終わる前に(上の「いつがいいか」のメールが来た数時間後(同じ日)に)掛けて来た。留守電の声は新人らしいが、本当に非常識なヴァカだった(上司の命令どおりのことをしているだけなのか)。待ってましたとばかりにブロックリストに入れた。ヒヒヒ。って、性格悪いな。

それにしても、そんなことまで入会時に承諾したつもりはないが、(ちゃんと読まなかった)規約に書いてあったのだろうか。ただ、メールに定例の「以後、不要な場合は−」のような文言すらなかったので、日本MSのクソ意識の低さを再確認した。

バカジャネーノ!

もちろん、一応試したけど未だにロックされていてサインインできず退会できないから、試用期間が終わるのを待つしかない。こんなのを ほんのわずか(1μgくらい)にでも使えるかと思って試した僕は、本当のクソだ。

→ (10/15 9:36) 良く考えたら、アカウントを放置したら、試用期間が終わったら残ったデータに課金される可能性があるから、退会した。それがすごく分かりにくく面倒だった。

最初はMicrosoftアカウントを削除するだけでいいと思ったのでそうしたが、アカウントが削除されるまでに待機期間(30または60日)があり、その前に試用期間が終わったら課金されてしまうので、一旦アカウントを復活させてストレージのデータを削除した。更に、MSのページによれば、Azureのサブスクリプションを解除する必要もあるとのことなのでそうした。カード情報の削除は アナログな方法でしか削除できず面倒なので、放置した。さすがに退会すれば使われないだろう。

もう二度と入りたくない!

 

PS. それにしても、データ量1TB、使用料月額約1ドルなんてゴミ誤差みたいなもので、他の大規模ユーザの隙間に生きるような感じだw そういうユーザが居るからこそ、僕のような趣味の者でも安価だけど高い信頼性で使えるのだ。そういう点では、GCSは(小さいほうの)スケーラビリティ(スモーラビリティ??)も高いと言えるのではないか。あるいは、銀行や政府のお金の計算のように、1円(あるいは銭)から兆以上までちゃんと扱えるってことだろう。

「兆」と書くとすごく大きく感じるが、実は1012で、データ量などではTで、実はそれほどでもない。PやEなどを扱うITの世界は、お金の計算を超越しているのだろうか?

そういえば、僕のスマフォの契約も500MB/月と似たような領域だ(爆) こういう技術(かどうか分からないが)も きっと何かに役立つはずだ。

こういう細かいのは米粒に文字を書くとか豆本とかの日本のお家芸みたいで好きじゃないが、それ自体を目的とする訳でなく、遊びとか興味を嵩じさせてやるのなら いいのではないかな?

あと、この場合、豆本に相当するのは、大きなデータをいかに圧縮するかみたいなことだと思う。そういうのは使いにくいし、情報量を落とす(非可逆圧縮)場合もあって本末転倒なので全く興味がない。この類の いい(悪い)例はi-modeだ。

 

(11/15 14:50 重複排除の効果の項を修正, 10/17 18:51 わずかに加筆)

  •  1
  •  0

非常時に備えて、滅多に使わないデータをクラウドのストレージにバックアップ(アーカイブ)する作業をしていて※、アップロードの待ち時間(平気で12時間とか掛かる)に、そのデータが必要になった時にリストアすることを考えたら、前提条件によっては なかなか難しいことに気付いた。

※今までに、約250GBの音楽データをアップロードした。

そのクラウドのバックアップが必要になる最悪の場合は、部屋にあるPCとバックアップHDDが全部駄目になった場合だ。例えば、震災や火災だろう。

なお、いずれの場合でもクラウドサーバは安全(壊れない)と想定する。そこが駄目な時は世界戦争とか地球が終わりなので まあいいかって気がする。

そのあとで(気を取り直して)PCのハードを手に入れてセットアップし、回線を繋げてデータをクラウドから戻そうとする時、クラウドの認証情報(パスワードの類)が必要になる。その時、僕はパスワードは全部ランダムに作り(当然、記憶できないのでパスワードマネージャに入れている)、更に、可能な場合は2要素認証にしている(ほとんどの場合、2要素目はTOTP(最初にQRコードを読ませるもの)である)ので、「パスワードを思い出して接続する」なんてことは全く不可能だ。

では、どうすればいい(しなくてはいけない)かというと、まずは以下だ。

  • パスワードマネージャのデータ(DB)を手に入れる。
    • これのマスターパスワードは覚えている。
  • TOTPのデータ(DB)を手に入れる。
    • これのマスターパスワードも覚えている。

今までは、それらはスマフォやUSBメモリに入れているから何とかなると思って居たが、最悪の場合(身体一つだけになった場合)は それらもなくなるから駄目だ。

上のデータを自分のファイルサーバに入れておくにしたって、サーバの認証も2要素認証だし、サーバにSSHで入って何とかするにしたって、鍵のファイルがないとログインできないようにしているから身体一つだけでは無理だ。

となると、なかなかいい方法が浮かばない。今思い付くのは、せいぜい以下のようなものだ。

  • 自分のファイルサーバに非常用の場所を作り、その認証はパスワードだけにする。
    • そこに上記データを保存しておく。
    • データは暗号化されているとはいえ、脆弱である。
    • 書いたあとで気付いたが、これのパスワードもランダムにしたら覚えられないという問題があるし、覚えやすくするにしても、既に上の2個(+α)があるから無理な気が・・・
  • 自分のファイルサーバでTOTPでない2要素認証をサポートする。
    • 例: 生体認証(指紋)
  • サーバのプロバイダに頼んで、仮想コンソールに入れるようにしてもらい(≒ パスワードの再発行)、そこで何とかして上記データを手に入れる。
    • あらかじめ、サーバに上記データを保存しておく。
  • 2要素認証のバックアップキーを紙に印刷して、肌身離さず持ち歩く。
    • これが可能ならスマフォやUSBメモリだってできるので、余り意味がない。

完璧ではないが手軽で現実的な方法としては、非常用持ち出し袋に予備のUSBメモリまたは(認証可能な)スマフォを入れておくとかだろう。ただ、これは情報の更新や常に充電しておくといった保守が欠かせないから、やっぱり弱い。

→ とりあえず、SDカードに上記データを保存し、財布のカード入れに挿し込んで持ち歩くことにした。さすがに避難する時に財布は持つだろうし、外出中に災害に遭った時も財布は持っているだろう。このSDは、定期的に上記データをバックアップしているUSBメモリと一緒にバックアップすることにする。これで少しは安心だ。

普通の(大きい)SDとmicro SDで迷ったが、microは薄く・小さくて いつの間にか財布から滑り落ちてなくなりそうなので、大きいSDにした。

→ その後、やっぱり小さくて薄いほうがいい気がしたので、クレジットカードサイズの、micro SDを嵌め込んで収納するケースを作った。国保の保険証のビニルケース(ちょっと大きくて使わないうえに、毎年もらえるので余っている)と厚紙を使った。ケース表面の片側が開くようにして、micro SDを出し入れできるようにした。

これなら、micro SDが窪みに収まっているうえに財布に入れている時は表裏両面から押されているので、滑り落ちることはないだろう。また、左右方向に曲げの力が掛かる可能性を考慮し、micro SDの たわみが小さくなることを期待して縦に置いた。 (10/7 9:04)

折角なので、これの前に作ったプロトタイプ(あるいは習作)の写真も載せる。クレジットカード型USBメモリ(→ : このデザイン、OKなの??)にインスパイアされて(実際には、ちょっと欲しかったけど、意外に高かったので)作った。

micro SDが脚(または腕)でケースに繋がったままアダプタに挿せ、脚を折ってmicro SDをケースの窪みに収納できるようにした。想定どおりに使えたが、どうも綺麗でないし、いろいろな部分が弱い感じだし、表面はmicro SDが剥き出しで嫌なので、上の正式版に作り直した。 (10/7 14:59)

まあ、身体だけになるのは まずないことだけど、最悪でそうなった時のための準備をしているので、イザという時に準備したものが使えないのであれば、単なる自己満足になってしまうし、その時に「あーーーー」(いろいろやったけど、無駄だったじゃないか・・・)と呻いて立ち直れないことになる。

とりあえずはプロバイダに頼むのが一番可能性が高そうだ。(日本の会社なので、)手間や時間は掛かるが何とかなるだろう。その時に本人確認の情報が要るだろうが、それは他にも必要なので、アナログな方法で何とかするのだろう。よくある、名前、住所、生年月日とかでいいかも知れないし、運転免許証(これも再発行してもらう)の写しが要るかも知れない。

他には、携帯電話回線(番号)に紐付いたストレージをキャリアやプロバイダが提供してくれれば、上記データを保存するのに使えそうだが、そのスマフォ(SIM)がなくなったら難しそうだ。ただ、上と同様にアナログな認証で再発行してもらえばいいのか。

基本的には、キャリアがこういう余計なサービスをするのには反対だが、非常用なら意味があると思う。容量なんて10MBくらいあれば充分だ。

書いたあとで思い出した。Googleなどは携帯電話(SMS)でアカウントを復活できるはずだから、まずスマフォを復活させれば※、ストレージ(例: Googleドライブ)にアクセスできるようになるはずだ。そこから あらかじめ保存しておいた上記データを取得すればいい。ただ、Googleのパスワードもランダムなので、覚えられない。これもリセットできるのだろうか? あと、アカウント名もランダムにしているものがあるので、おいそれとは復活手順にすら進めない。できそうな感じではあるが、なかなか難度が高そうだw

※これにしたって、Androidを最初に使う時にGoogleアカウントを入れる必要があり、そこで つまづきそうだ。 → まずはPCからGoogleのアカウントを復活させ、それでAndroidを初期設定することになるのか。いや、それだとSMSが受け取れない。鶏と卵の問題かな・・・ 電話での復活もできたっけ?

アナログな認証をクラウドにも使えればいいが、Googleなどは融通が効かなそうだし、海外の会社に事情を分かってもらうのは大変そうだし、名前や生年月日とかで信用されたら、いくらでも乗っ取りができてしまう。電話代も高いw

あとは、例えば眼鏡にメモリが内蔵できれば、単体のUSBメモリよりは可能性が高い。それから、身体にNFC対応のメモリを埋め込むとかバックアップキーをタトゥーで彫るのは確実そうだが、ちょっと遠慮したいw

代わりに、バックアップキーを印刷した布をすべての衣類(下着も含む)に縫い付けるほうが、痛くないし更新可能だから まだ良さそうだ。さすがに素っ裸で避難するってことは ないだろうw

 

書いたあとで思い付いたのは、データを文章にして(あるいは、文章に埋め込んで)、マスターキー(これは覚えている)でデータを抽出できる方法(昔のゲームの「呪文」みたいなもの?)だ。他人が読んでもなんでもない(けど、例によって随分長い?w)ブログのエントリ(あるいはサイト全体)だけど、僕だけは分かっていて使えるってのは おもしろそうだな(画像はステガノグラフィが有名だが、テキストでもきっと既にあるだろう。あと、MQAみたいに音のファイルに入れるのもできそうだ)。ただ、AIに見破られる可能性もありそうだw

 

考えれば、他にもいい案が ありそうだ。すぐにできる必要はないが、何か用意する必要はある。「必要」とは書いたが、(今はその事態になっていないので、)「いろいろ考えて楽しんでいる」と言うほうが正しい。ただ、「あーーーー」と呻きたくはないな。

まあ、これらが必要にならずに終わるのが一番だ。

  •  0
  •  0

先日から試している、長期間変更しないデータのGoogle Cloud Storage(以下、GCS)でのアーカイブ保存(バックアップ)。やってみないと分からないことは多いもので、予想していなかったことが いろいろあった。

バックアップ方法 (使用プログラム・設定)

当初はrcloneで始めたのだが、使っているうちに少し不満な点が出た。Sym-linkに対応していないことである。当初は それほど使っていないと思って、(例えばバックアップ時にsym-link一覧も保存し、)リストアする時にでも対処すればいいと思って居たのだが、実は結構使っていた。音楽についてはそうでもないが、写真(当初は予定していなかったが、古いものは対象にしたくなった)では多用していることに気付いた。

書いたあとで思い付いたが、バックアップ時に(一覧でなく)sym-linkだけを格納したtarを一緒に保存すればいいかも知れない。これなら、面倒な作業やスクリプトなどが要らず、コマンド一発で復元できる。ちょっと考えよう。 (17:39)

スクリプトを作れば いくらでも復活できるが、(それにしたって動作確認やデバッグは必要なので、)なるべく手間のないほうがいいと思うので、duplicacy(ファイルをチャンク(数MB程度のブロック)に分割して保存しているので、sym-linkも保存できる)を再検討した。

すると、duplicacyでは、sym-link対応の他にも、ファイルの移動や名前変更の時に再転送が不要になる場合があることが分かり※、なかなかいい感じになった。

※詳細な動作や条件は把握していないが、ファイルをブロックに分割して保存しており、同じブロックが書き込み済みなら再度書き込まない(重複排除, deduplication)ため。実際にバックアップ済みディレクトリを移動してから再度バックアップしたら、アップロードなしで済んだ。

なお、duplicacyで定期的に実行するprune(ファイルの更新・削除のために不要になったブロックを削除する)処理のコストは不明だが、ストレージ自体のコストは安いし、そもそも変更しない前提のファイルをバックアップしているので、pruneしなくてもいいかも知れない。

この辺りは昔のWORM光ディスクでの保存に似ている感じだ。

そして、昨日からduplicacyに切り替えて試していたら、新たに気になることが出た。上に書いたように、ファイルをブロックに分割するので、ブロックが小さいと書き込み・読み出し回数が増えたりストレージ内のファイル(オブジェクト)数が増えて、効率が悪くなったり料金が増えたりするのではないかということだ。試算してみると、当然ながら、ブロックが大きいほうが書き込みのコストは小さかった。

そこで、今朝、デフォルトのチャンクサイズが平均4MB(1..16MB)なのを、8MB(2..64MB)に変更して試して居る。

ただ、バックアップやリストア、それに伴うNW転送に関してはファイル数でなくデータ量に課金されるので、チャンクサイズはトータルのコストには余り効かないようだ。それでも、チャンクの管理(実際にあるかは不明: チャンク一覧やpruneの時か)のための操作数は減るので、その分のコストは下がるはずだ。あと、バックアップ速度は少し速くなった気がする。

運用コスト (料金・費用・手間)

料金をチェックしたら意外に高かった。昨日は72円で、4日目の今朝は85円になっていた。※

※絶対値としては とても安いが、まだデータ量が少ないのに予定している月額(< USD 1)を容易に超えそうな勢いなので、不安になった。

いろいろ試したせいもあるが、それでも なんか高いので調べてみたのだが、GCSは料金の内訳が出ないので、どの処理・操作が主因なか分からなかった。それで、1GBくらいをアップロード(バックアップ)した時の処理数や転送量と料金表で試算してみたが、上の料金には合わなかった。

気になったので、試しにリストア時の費用も試算した。想定している上限の約1TBをリストアする場合を計算したら、思わぬことが分かった。※ NW転送(外向き、"egress")とデータ取り出しのコストがかなり高いのだ。上に書いた、書き込み(リストアでは読み出し)操作よりずっと高い。

※上記のように自分で試算した額と請求額が合わないので、下の試算も合わない可能性があるが、データ取得と転送については合わない理由がないと思う。

以下に約1TBをリストアする場合の料金の試算結果を示す。 (USD → JPYは今は約111円のようだが、とりあえず120円とした。)

  • データ要求操作(get= Class B(USD 0.50/10000 reqs)とする)
    • duplicacyのチャンクサイズが平均10MBの場合
      - 1024 * 1024 (MB) / 10 (MB) = 104858 チャンク → 104858 /10000 * 0.50= USD 5.2
  • データ取得(アーカイブからの取り出し) (USD 0.05/GB): チャンクサイズには関係ない)
    • 1024 (GB) * 0.05= USD 51.2
  • データ転送 (Egress to Asia: USD 0.12/GB): チャンクサイズには関係ない)
    • 1024 (GB) * 0.12= USD 123
  • 合計: USD 179 → 約2.1万円

合計額もそうだが、データ転送コストの高さに驚いた(ボッタクリ??)。他社(Azure, S3)はこの数分の一(Azureは書いてなかったので無料なのかも知れないが、不明)なので、Googleは ここらでコストを回収しているのだろうか?

データ転送料金はArchiveだけでなく全クラスに共通なので、普通に使っている人は かなり高くついていそうだ。だから、実はGCSのユーザーは少ないのだろうか? そして、Googleの多くの過去のサービスのように消滅してしまう?? あるいは、電気代のように逆従量制(?)なので、大規模ユーザーが多いのか?

なお、ブロック分割しないrcloneでも同様に試算したが、データ要求操作のコストは安いものの他より1桁小さいので、合計はUSD 3程度しか安くならなかった。

それで、またAzureやS3に目が移りかけたのだが、当然ながら いいことばかりではない。次が主要な判断事項となった。

どちらがいいか?

  • リストアすることは まずないので、リストア関連料金は高くてもいい? (平常時(保存だけ)の運用コストがBackblaze B2より安ければいい?)
    • 候補: GCS
      • 即座にリストアできる。
      • duplicacyが使える。
  • リストアに手間や時間(解凍時間)が掛かってもいいから、特にリストア時の料金が安いほうがいい?
    • 候補: S3かAzure
      • リストアできるようになるまで(「解凍」)、10時間以上掛かる。
      • duplicacyは使えない。(バックアップ時にストレージに保存されたconfigが取得できないし、(あるかは不明だが)チャンクが読めないので) → configだけクラスを変えればいいかも知れない。
      • rcloneでもファイルの属性が読めるか不明。: 実体でないから おそらくできる。
    • AzureはデフォルトのクラスをArchiveにできないので(CoolかHot)、バックアップ後に変更しなくてはならず、使いにくい。S3は不明。
    • S3やAzureでリストア時に解凍すると、クラスが上がって保存料金が高くなる(約10倍)可能性がある。
      • 短期間なら問題ないが、リストア後にクラスを戻す手間が増える。

滅多に使わないのだから、まず起こらない場合の手間を惜しまずに運用費を安くすべきなのか、そうは言ってもたまに間違いを起こして(僕は これが結構あるw)使う可能性はあるから、手軽に・間違いなく使えるほうがいいのか。  (当然ながら、今の考えは後者である。) − 悩ましいところだが、GCSの試用期間・額はたっぷりあるので、試行錯誤しながら考えたい。

余談だが、GCSの試用額(この額・枠のことを"credit"というのだろうか?)約3万円が無期限で使えれば、僕が使う予定の十年分以上になるから即座に決めるが、そんな うまい話はないwww

書いたあとで、掲示板のまとめのマイナンバーカードに関するスレッドを読んで、上の2つの選択肢はマイナンバーカードと運転免許証の関係に似ていると思った。マイナンバーカードは無料だけど、随分手間が掛かる(そもそも、さほど便利でない)。一方で運転免許証は、取る時も維持にも多少お金が掛かるけど、面倒さは少なく、手軽に幅広く便利に使える。

「どっちがいい?」と聞かれれば(聞く人すら居ないだろうが)、間違いなく後者に決まっている。

細かいこと

GCSを使っていて、(やっぱり)気になること・不満なことが出て来た。

  • 料金の詳細(内訳)が分からないのが不便。Web(コンソール)では見られない。 → コンソールのBillingのReportsの右側のフィルタを設定すると項目ごとの料金を表示できる。が、円なので使用量は分からない。逆算するにしても、正確には分からない。 (10/5 7:41)
    • B2では分かる。予測額も出る。
    • 月の料金請求時(確定時)まで分からない?
    • 料金(当日までの合計額)が出るのが遅い。: 10時頃更新?: 毎日の0:00 UTCから集計するとしたら、仕方ないか。
  • データ量などが更新されるのが1日1回なのも不便。
    • リアルタイムに出ず、更新は料金より遅い(午後3時頃?)。 (→ : 最下部の"Total bytes"と"Total ojects"が実際より小さい。: 前者は、少なくとも、右下の"Rec bytes"(≒ 書き込んだデータ量)程度はあるはずだし、実際に求めても そのとおり。)
    • B2では月1回なので、仕方ない?
  • Web(コンソール)の監視系、料金系が 今ひとつうまく動かなかったり、使いにくい場合がある(要するに、出来が悪い・詰めが甘い)。
    • Googleらしい? ここら辺はAzureのほうが良さそうな気がする。
    • B2はずっと良い(というか当たり前に使える)ので、すごい落差を感じる。

 

GCSのwebのモニタ画面 (苦労して見やすくした。)

 

希望・期待・・・

まあ、個人的に一番好ましいのは、Backblaze B2がアーカイブクラスのサービスを出してくれることだが、難しいのではないか。まず、今時テープとかありえないし(彼らも慣れてないし)クソ使いにくいので、HDDやSSDを使うとしたら、どうやって料金を下げるのだろうか。それが無理なので、今のように単一サービスで通しているのだろう。

が、何か引き換え(アーカイブは滅多にアクセス・変更しないことからの何か)があれば、実現できそうな気がする。とりあえずは、GoogleのようにNW転送料金を高くする??

通常時はストレージの電源を切っておいて、アクセス時だけonにすることも考えられる(それなら何時間も掛からない)が、信頼性が下がる可能性があるので(HDDは何年間も動かさないと固まってしまう)、余りメリットがなさそうだ。「それでもいい」という代わりに安くするのはありかも知れないが、本当に駄目になっていたらバックアップの意味がないし(それを避けるために、冗長化するとか たまに動かす?)、制御が面倒で(停めて浮いた電気代より)高く付く気もする。

 

なお、現実的な解はGCSかAzureだろう。MSは大10嫌いだが、GCS(RCP)のwebコンソールや料金(アカウンティング)関係のいい加減さには ものすごく呆れたし、みすみすぼったくられるのも嫌なので、コスト次第ではAzureも充分ある。あと、AWSはもっと試用できるようにして欲しい。まあ、そもそも彼らは僕みたいな「最大1TB」とか「月1ドル未満」なんていう超小物じゃなく、PBオーダーの人たちを相手にしているのだろうから、仕方ないとは思う。 (18:49)

ちょっと試そうとAzureにサインインしようとしたら、何も規約違反をしていないのに、なぜかアカウントがロックされていたので、Azureの検討はしない。やっぱりMSは最低だ。わずかにでも期待したのが馬鹿だった。 (19:21)

 

結局、

上記のように、Azureは「やる気あるの?」レベル(調べたら、何もしてないのにアカウントがロックされるのは良く起こるようで、Officeなどが使えなくなって困る人が多いようだ)だしS3は「一見さんお断り」なので、(他に選択肢がなくて)GCSを使うことにした。その関係で、バックアッププログラムをrcloneにする理由がほとんどなくなったので、duplicacyを使うことにした。今日から少しずつ音楽などのファイルをバックアップして、様子(特に料金)をみていく。 (10/5 10:58)

 

おまけ: duplicacyでちょっと引っ掛かったこと。

GCSのアクセストークンのファイル(例: gcs-token.json)を、ストレージの初期化時(duplicacy init実行時)に指定した場所から移動したら、エラーでアクセスできなくなってしまった。

ヘルプやドキュメントには変更の仕方が載っていなくて、また初期化が必要かと がっかりしたが、設定ファイルやPC内にはそれが格納されている気配がなく、当然、クラウド側には保存されていない(トークンがないとアクセスできない)から、どうにかしているはずだと思ってソースを見たら、分かった。

  • 初期化時に設定したパスは、LinuxではGnome keyringに格納されている。 (使っているとは思いもよらなかった。見付からないのも当然である。)
    • seahorseコマンドで変更可能。: Default keyringの"gcs_token - duplicacy"
  • また、設定ファイル(.duplicacy/profile)中の"keys"ブロックに"gcs_token"のキーでパスを書けば変更できる(duplicacy set -key X -value Yでも設定できるはずだが、試していない)。
"keys": {
  "gcs_token": "/home/user/GCS/gcs-token.json"
}
  • また、環境変数DUPLICACY_GCS_TOKEN, DUPLICACY_PASSWORDでも指定できるはず(試しては居ない)。
  •  0
  •  0