Archive for the ‘Linux’ Category

乗り換えたばかりのZettlrは使い込むと駄目だった。Electronのため、大きいノートの編集が遅くなるのが一番イライラする(日本語なんて、入力に追いつかなくて ひどい)。※あと、余計な補完だの書式を勝手に変える(勝手に破壊して、なかなか直せないことがある)とかも、やっぱりイライラする。

※JavaScript≒ブラウザでテキスト・画像その他を処理しているので、どうしても無理があるのではないか? 最新のマシンなら問題ないのかも知れないが、元々効率が悪いものだけど すごい環境で動かせばいいという思想なのだろうか? まあ、Intelには馴染みが良さそうだw

そもそもMDが嫌いだ。書いている途中で いちいち書式を思い出したり調べたり、(エディタのせいでプレビューがおかしくて)調整するなどと、本質でないことに手間が掛かって書くことに集中できないし、見た目も煩雑だ。※ 今は流行っているが、僕にすれば全く奇妙な現象で、そのうち もっといいのが出て来て廃れるのではと思う。

※文章に書式指定が混ざっていて、良く普通に読めるものだ。MD愛好家・信者は そういうのが透明にでも見えるものなのか。至るところに混在していても「ないもの」にできる? 全く器用だ。

そこで浮上したのがZimである。前にも書いたように、これはワープロほど高機能ではなく、"Desktop Wiki"を自称しているように とてもシンプルなものだが※、僕がノートを書くには必要充分で、まさに「こういうのでいいんだよ」だ。あと、(ElectronのJoplinに比べて)超省メモリ(約1/3-1/10!)なのも 好感が持てる。もちろん高速だ。

Zim:  「こういうのでいいんだよ」って感じ^^

※ツボは押さえており、ちゃんと上/下付き文字もできるw もちろん、画像も貼り込める。

気になるのは、作者が多忙(あるいは疲労?)で いつ終了するか分からず、そこまで行かなくても、この先も改良される期待ができないことだ(それでも、細かい修正は続いている)。まあ、オープンソースなので、終了する時はソースを引き取って自分で面倒見ることも可能だと考えて、使ってみることにした。

 

ただ、僕の使い方(スマフォからもアクセスしたい)としては、Zimはノートの共有・同期の機能、あるいは それを補助するような機能を持っていないのが困る。※

※実際にはwebサーバの機能が内蔵されていて確かに動くが、Zimの完成度や作者の状況を見るに、このサーバをインターネットで使うにはセキュリティ面でのリスクが高過ぎるので、「持っていない」と書いた。もちろん、使いたい人は使えば良い。

いろいろ検討したが、スマフォからのアクセスに関しては、どうにも いいものがない。Dropboxなどのファイル共有でZimのノートやMDなどを共有すれば、MDエディタで見られる(MarkorはZimのノートをサポートしている)。が、残念なことに画像が表示されない。事前に画像もスマフォに同期しておけばできるが、見るかどうかも分からないノートと画像など全部を常にスマフォに同期しておくのは余りにも効率が悪いし、電池や通信データ量を浪費する。

逆に、ユーザが指示した時だけ同期するソフトだと、ノートを見たいだけなのに、まず「同期」の操作をし(て、同期を待た)なくてはならず、面倒この上ない。そんなの忘れて古い情報を見てしまうか、面倒で使わなくなってしまうだろう。

もう一つ、ノートをHTMLに変換してwebサーバに置けば、スマフォからのアクセスはとても容易になる。上に書いたような同期は不要で、必要な情報だけがダウンロードされるし、特別なアプリも要らない。が、いろいろなノートを全部平文で格納してwebで公開(もちろん認証する)するのは多くのリスクがあって、かなりの勇気と慎重さが要る。

そこで出て来る(生き延びているw)のがJoplinだ。Joplinも実際にはノート全部をスマフォにダウンロードしておくようだが、画像はノートを開く時にダウンロードするので効率が良い。また、不具合のおかげなのだろうが、設定していてもバックグラウンドで同期しないので、アプリを開かない限り電池も通信量も消費しない。その代わり、アプリを開いた時に同期が終わるのを待たないと(そのあとで再度同期が要る場合が多い)、ノートが最新にならない(同じアプリなので、面倒さは少ない)。

という訳で、最新のシステム概要は以下のようになる。

  • PC
    • 僕: Zimでノートを作成・変更、表示する。
      • 当初はJoplinのノートを変換して取り込むことが多いので、そのためのプログラムを作成する。
    • ノート変換・更新プログラム: (スマフォで見たい)ノートが作成・更新されたらMDに変換し、Joplinに入れる(ノートが既にあったら更新する)。
      • 自動で行うようにする予定。
    • Joplin: サーバにノートを同期(アップロード)する。
  • サーバ: ノートを格納する。
  • スマフォ
    • Joplin: サーバからノートを同期(ダウンロード)する。
    • 僕: Joplinでノートを表示する。
      • ノートの更新はせず(Joplinが重いので諦めている)、記録は別のシステムを使う。

そして今は、いくつかのノートをZimに移して機能や操作性などを確認しつつ(ダメ出し+習熟)、ZimとJoplin間のノート変換・取り込み/更新プログラムを作っている。

システムを作る際にZimのいい点は、グラフィカルに(WYSIWYGで)書式設定できるにも関わらず、ノートのファイルが非常に単純なテキスト形式(MDに近い)なので※、テキスト処理ツールで自由に処理できることだ。

※紛らわしいが、ZimのファイルフォーマットはZIMというファイルフォーマットとは異なる。なので、前者は"Zim-wiki"などと書かれることがある。

また、意外なことにpandoc(テキストフォーマット変換プログラム)がZim形式での出力("zimwiki")に対応している(JoplinのMDを入力するには"gfm"を指定するのがいいようだ)※ので、MDからの変換が可能だ。また、Zim自体でMDへのエクスポートが可能なので※、pandocと併用すれば、一応はMDとの相互変換が可能だ(今までのところ、MD-Zimの変換・逆変換をしても書式は崩れていない)。

※なぜか、pandocはZim形式での入力はできず、ZimはMDのインポートができない。

 

今まで同様、このシステムも、いつ気が変わって「はい終わり」になるか分からないが、まあ、苦労して作ったからと言って特に固執せず、その時々で良い・使えるものが できれば・見つかれば良いスタンスだ。

永遠のプロト・PoCか、継続的スクラップアンドビルドか、あるいはシステムの焼畑農業か星一徹式開発か?w

 

PS. Zimを使っていたら、早速思わぬ欠点に気付いた。引用の書式がないのだ。あと、段落のちゃんとした(綺麗な)インデントもない。※ 良く使うものだが、ないものは仕方ない。作者なりの考えなのだろう。

※ちゃんとしたインデントはあった。MDにエクスポートする時になくなってしまったようだ。そうだ、EvernoteからJoplinに移行する時に、MDにはそういう概念がなくて困ったのを思い出した。その時は">"を使った。

代わりに、例えば、引用部をコードブロック(verbatim)にするとか、斜体にするとか、上下を目立つマーク(例: "+++")で挟むとか、MDのコードブロックの記号で挟む("```"などは そのままMDに行く)などの代替ができる。他には、単に段落をインデントさせるのもいいかも知れない。

作者としてはverbatimを使うことを想定したと思う。それは間違っていないのだが、そうすると引用部に書式が付けられなくなくなってしまうのが、不満なのだ。まったく、「シンプルなのでいい」と言っていた舌の根が乾かないうちにw

それから、インデントは、まあ、箇条書きで代替すればできるし、現状でも「綺麗でない」インデントは可能だ。

でも、何となく気に入らないので追加したい気もするが、やり過ぎだろう。 (11/9 19:16)

本体を改造するのはハードで やりたくないので、別件で見付かった余計な変換(例: "//...//"が"*...*"になる)を吸収するのと一緒に、MDへのエクスポート前にノートを変換して何とかした。

引用部はインデントすることにすると、ZimはインデントをTABで表現しているが、MDにエクスポートする時に削除されてしまうので、エクスポート前に、とりあえずMDのblockquote(">")のTABの数分繰り返しにして、MDに残るようにした。 (11/10 18:55)

  •  1
  •  0

先日からJoplinのエディタの代わりに使い始めたMDエディタ、QOwnNotesは なかなか良い。が、前回も書いたけど、完璧ではないので使っていると問題は出て来るので、気になるものからフォーラム(正確には「問題報告ページ」だろうが、ここでは簡単に「フォーラム」と書く)に投稿して対応してもらっている。

その対応がなかなか良くて感心している。言葉はぶっきらぼう簡潔だけど、ちゃんと対応する気が感じられるのがいい。しかも速い。そこら辺は昔やっていたMusicBeeに似た雰囲気で、懐かしい。

(11/4 17:02) が、(忙しいせいか)結構いい加減かつクソ野郎癖の強い人で、なかなかイライラすることがあった。が、他にいいエディタがないので今は使うしかないと、諦めている。その代わり、寄付はしない。

(11/4 18:53) いつもの「坊主憎けりゃ」で、使うどころか画面を見るだけでもイライラするので、QOwnNotesは止めた! 少々物足りないけど、安心感のあるZettlerに戻る(とりあえず今はねw)。

 

そういう問題の中で一番最初に何とかしたかったのは、日本語(Fcitx+Mozc)の未確定入力(pre-edit text)に下線が出ないことだ。落ちるとかでなく表示だけの問題なので、致命的ではないのだが、エディタで文章を書いている時には、どこからが変換対象なのか分からない(候補を良く見ればいいかも知れないが、書くのを邪魔される)のは結構なストレスだ。ただ、普通のアプリは出るのが謎だった。

検索してみると、いくつか情報が出て来た。いいヒントになったのは、LibreOffice(実際にはKDE?)のフォーラムへの報告だった。更に、fcitx-qt5のフォーラムに まさにこの問題が報告されていたのだが、作者の環境では「起こっていない」で未解決(と思われる)のまま閉じられて仕舞っている。

どうやらQt5アプリとFcitxの組み合わせで起こるようだ。実際、いくつかのQt5アプリで試したら ほぼ全滅だった。以下に結果を示す。

  • 下線が出ない。
    • digiKam7, QuiteRSS, QtQR, SMPlayer, VLC, FeatherPad, Calibre, Nextcloud, KeePassXC
  • 下線が不完全に出る。
    • LibreOffice Writer
  • 下線が出る。
    • LibreOffice Calc

確かにdigiKam(7からだったと思う)では下線が出なくて使いにくかったが、この問題のせいだったことが分かった。

それで、これはQOwnNotesの問題ではないのだが、fcitx-qt5の作者は問題が起こって居ないスタンスで解決の見込みがないので、QOwnNotesもLibreOfficeと同様な対応をしてもらえないか聞いてみたが、さすがに無理だった。(出て来ないが、「無理強い」の今の言葉だw ← 「無茶振り」だw)

その時はQt5の問題と思ったが、実際には、Fcitx(fcitx-qt5)の問題のようだ。ただ、Qt5がfcitx-qt5に下線を描くように指定していないせいだとしたら、Qt5の問題だ。この辺りは分からない。

そこで、「ちょっと何とか」できないかと思ってQOwnNotesのソースを見たが、上のLibreOfficeのパッチを適用するところに相当する部分はなく、未確定入力に関しては何も処理していない(確定した文字列を受け取って処理しているだけ?)と想像した。そこでfcitx-qt5のソースを見たら、(無理やり)下線を出す方法が分かった気がしたので やってみたら、たった1行の修正(削除)だけで見事に出た!

この変更は、本来 文字列に指定された(そういうことがあるのか?)スタイルに関係なく、無理やり下線を出しているので どこかで問題が起きそうだが、2時間くらい使った範囲では大丈夫だ。

ただ、他のQt5でないアプリでは下線は破線でなく実線なのが気になった。少しソースを検討したら、本来はデフォルトで実線の下線を描くつもりのようで、指定されたら破線にしているようだ。それがなぜか、実線の下線すら描いていない。Fcitxの設定があるのか調べたが、なかった。

そこで、とりあえず、破線の下線(DashUnderline)の指定がない場合(デフォルト)は実線の下線(SingleUnderline)を描くように修正した。参考までに、以下に修正したソースの関連部分を載せる。変更箇所は"Default to draw underline."辺りである(行頭の":"は省略した部分)。

platforminputcontext/qfcitxplatforminputcontext.cpp:

void QFcitxPlatformInputContext::updateFormattedPreedit(
 const FcitxFormattedPreeditList &preeditList, int cursorPos) {
:
    if (preedit.format() & TextFormatFlag_Underline) {
        format.setUnderlineStyle(QTextCharFormat::DashUnderline);
    } else { // Default to draw underline.: Butty: 2021/11/3
        format.setUnderlineStyle(QTextCharFormat::SingleUnderline);
    }
:
    update(Qt::ImCursorRectangle);
}

※上のソースコードのオリジナル部の著作権は、オリジナルファイルの先頭に記載のとおり。

 

妙なのは、これが全然問題になっていないことで、ひょっとすると僕とか特定の環境だけで起こり、世の中の多く(実は少ないのか?)の方は普通に使えているのかも知れない。であるので、本来は こういう修正は作者に連絡してオリジナルに入れてもらうべきだが、上記のように作者が「起こってない」スタンスということもあって保留した。

(11/4 12:19) その後、別件で「まっさら」かつ僕のとは別な環境(KDE neon)で試したところ、やっぱり問題は起こったので、少なくとも僕だけの問題ではないようだ。ただ、Ubuntu系だけかも知れないし、そもそも作者が上記のとおりなので、報告は保留する。

 

もし、この投稿を読まれて「自分のところでも起こっている」という方が多いなら、オリジナルに入れてもらうようにします。そういう方は、コメントを書いて下さるか、「いいね!」か「そうね!」を押して下さい。

あと、「とりあえず、自分も直したい」という方がいらっしゃたら、もう少し詳しいやり方(と言っても、ビルドの方法、ビルド時にエラーが出た時の対処、インストール方法程度)を書きます。ただ、上の記述で分からない方ですと、理解して頂けるように書けるか不安です。

 

とりあえず、また一つ問題が解決して、(しかも、QOwnNotes以外もザクっと直って)気分がいい。そして、QOwnNotesは(気になることは他にも もう少しあるけど、)さらにサクサク書けるようになった^^

 

PS. 僕の「ちょっと何とか」は、大体ちょっとどころじゃ済まないが、今回は大丈夫だったwww でも、忘れた頃にトラブる可能性はある。

  • QOwnNotes

    QOwnNotes

    Open source markdown note-taking for Linux, macOS …

  •  1
  •  1

結構前に書こうと思ったけど、良く確認してから投稿しようと思い、その後全く問題が起こっていないので確かそうだ。

僕のPCとルータの相性なのかも知れないが、スリープからの復帰後にNWが使えなくなる問題があった。一番最初に使っていたバッファローのルータ(WHR-G301N)では起こらなかったが、次のバッファローの新しいもの(WSR-300HP)では起こったので、ルータの仕様が悪いのかと思って使うのを止めた。

その後、IPv6(IPoE)対応にするためにI/Oデータのルータ(WN-SX300GR)に換えたら また起こったので、これも駄目かと思った。

なので、バッファローには濡れ衣を着せてしまった。申し訳ない。

バッファローの旧と新(I/Oデータも)の違いはGigabit Ethernet対応かどうかなので、その辺りと僕のPCの相性なのかも知れない。

が、通信速度の低下を少しでも減らすためにIPv6は使いたいので、「何とか」した。想像だったのだが、PCのスリープからの復帰をルータが ちゃんと認識していないのが原因ではと思った。それで、ルータのポートからPCのケーブルを「抜き挿し」するのを擬似(電気)的に実現しようと、スリープからの復帰時にNW-IFを一旦落としてから上げるようにした。

少し詳しく書くと、nmcliというコマンドで、(connectionでなく)deviceレベルでNW-IFの機能を停めて(down)から起動(up)させた。

とりあえず問題は解決したので、少し前まで使っていた。ただ、ちゃんとした対処でないし、復帰時に一旦NWが切れるのでちょっと気分が悪かった。IPv6のネゴシエーションは遅いようで、少し(数十秒)時間が掛かるのが嫌だった。

それが、先日のQuad9のDNSサーバが遅い問題に対処した時にNWを いろいろいじっていたら、NW-IFを落とさなくても済む方法、つまり、「ちゃんとした」対処方法が分かった。

まず、スリープからの復帰後にNWが使えなくなる問題の直接の原因は、復帰後に(PC(Linux)の)DNSサーバの情報がなくなってしまう※ためだ。そのため、IPレベル(例: IPアドレス直打ち)ではちゃんと通信できるものの、ホスト名で外部にアクセスしようとしてもIPアドレスが分からないために通信できなくなっていた。

※その原因は分からない。いつもながら不勉強で、この辺りは分からないことが多い。

それで、スリープに入る前にDNSサーバの情報を保存しておき、復帰時に再設定するようにしたら、万事うまく行った。

めでたしめでたし。

この時に思い付いたもう一つの解決法は、NW-IFを一旦落とすのにnmcliのconnectionを操作するものだ。ただ、スリープからの復帰時にconnectionを有効にするのに時間が掛かるのと、DNSだけでなくルーティング情報も保存する必要があり、また、IPv6の一時アドレスがリセットされるので、今ひとつ好みでないので却下した。

 

でも、他の人は特に困っていないようなのが謎だ。やっぱり、相性みたいなものがあるのか?

  •  1
  •  1

(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

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

それで、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

いつものように四苦八苦しつつも(そのため、気付いたら前回から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

今日の昼近くから、突然、LinuxのJoplin(デスクトップ版)が同期エラーになった。エラーメッセージは"certificate has expired"(サーバの(SSL)証明書が期限切れ)だった。いやいやいや、証明書はちゃんと定期更新されているし、ブラウザもカレンダーもAndroid版Joplinも問題ないのだが・・・

それで、試しにJoplinの設定で証明書エラーを無視するようにしたら ちゃんと同期するので、それで(何かわからないが、悪いところが)直るまでしのごうかと思ったが、気分が悪いので調べてみた。すると、思わぬところに原因があった。

Joplinのフォーラムでは、例によって「Joplinは証明書は使っているだけだから知らねーよ他が悪い」みたいな回答があったが、更に調べると、Joplinを動かしているElectronの問題で、他にも困っている人が多そうだった。Electronはメモリを食う(しかも、まず解放しない)から大嫌いなので原因までは調べなかったが、大方、証明書の格納領域が小さい(僕が使っているサーバの証明書は、Let's Encryptのものなので3段階になっている)とかなのだろうと想像している。

ただ、なぜ今になって急に出たのかは謎だ。もしかしたら、昨日Joplinを更新したのが関係あるのか(だったら、Joplinにも何か原因があるはずだ)。

それで、暫定対処方法が分かり、どうにか、上記の証明書エラーを無視する設定を解除してもエラーが出なくなった。こういう分かりにくいところが駄目になると探すのが大変で、まったく疲れる・・・

参考までに、関連するページを僕が参照した順に載せる(()内は投稿時期(JST))。

対処のポイントは、上に書いたように、証明書が3段階になっているのが悪いから減らすことのようで、証明書を作成・更新する時に中間の(あるいは余分な)証明書を削ればいいようだ。※ 中間のものは必要だから入っているはずなのに、どうして削っても問題ないのか まで考えるつもりはないが、確かにちゃんと動いている。中間の(あるいは余分な)証明書を削っても、削ったものが最後(「最初」のほうが正しいかも)の証明書に含まれているようなので、それでいいのかも知れない。

※例えば、(僕は使っていないが、)certbotには以下のように指定する(webサーバにnginxを使っている場合)。太字部分の指定で中間の(あるいは余分な)証明書を削るようだ。

sudo certbot certonly --nginx -d <domain> --preferred-chain "ISRG Root X1"

他に、試してはいないが、webサーバの証明書ファイル(例: "fullchain.crt")の中の2番目のブロック("-----BEGIN CERTIFICATE-----"と"-----END CERTIFICATE-----"に挟まれた部分)を削ればいいのではないかと想像している。

 

(10/2 5:04 わずかに修正)

  •  1
  •  0

先日書いたspicetify-cliのCSSを改造して できるようにした。結局、Spotifyアプリの実体はHTMLで、元々はコピーできるのだが、なぜか無効にしていたので、それを再度有効にすればいいだけの話だった。

こういうことは今までにも何度も見た(例: Webで右クリック禁止)が、全くクソ馬鹿野郎だと思う。考えが浅はかだ。そうやってユーザーの利便性を落として、どういう意味・価値があるのか。そんなに自分の財産を保護したいなら、公開せずに後生大事に金庫にでも保存していればいいのに! もし意識せずにそうなったのなら、もっと低レベルだ。

文学作品だったら少しは分かるが、単なる技術的とか豆知識とかの類でコピペ禁止にしたって、嫌がらせ以外に何の意味もないよ。

文学作品や歌詞だって、データをコピーするのはユーザーの自由で、それを合法的に使うのには何の問題もないのに、最初から疑ってできないようにするのは ちょっと違うと思う。

CSSは得意でないので結構苦労したが、基本的には、CSS中でコピーしたい要素の user-select プロパティを text などに変更すれば良い。

苦労したのは、以前の版(現行もそうかも)のSpotifyアプリのCSSがぐちゃくちゃで、同じような要素が別のクラスになっているので、「探しては設定する」を何度も繰り返した(そこまでする必要はなかったが、ついムキになったw)。

参考までに、以下に、以前の版(1:1.1.68.632.g2b11de83)のSpotifyアプリに対するspicetify-cli(1.2.1)のデフォルトのテーマ(SpicetifyDefault)の改造版のuser.cssへの追加分を載せる。ただし、他にもいろいろ変更しているので、これだけではうまく行かないかも知れないし、残った(コピーできない)部分があるかも知れない。でも、基本的なアイデアはこれだけ(コードは長く見えるが、主要部分は下から2行目のたった1行だけ)だ。

/* Make texts selectable.: Butty */
/* Not effective/useful in some part (eg. tracks in track list). 
  Because, possibly, the draggable attribute is set by JS.: TODO */
[draggable] {
  user-select: unset;
}

#document, /* Not enough: Reset later by JS. */
/* For playlist page. */
.glue-page-header__content-inner, 
.playlist-content,
/* For album page. */
.Header__content, 
.AlbumRoot__content .glue-page-wrapper,
/* Sidebar and player control (bottom). */
.LeftSidebar, .view-player, 
/* Others. */
.tracklist-album, .tracklist-chart, .tracklist-basic, .tracklist-playlist, 
  .tracklist-podcast, .tracklist-popular, .tracklist-station, .tracklist-queue, .tracklist-search,
.HomeRoot, .MadeForYouRoot, 
.RadioHubRoot, .RecentlyPlayedPage,
.App__description, .app-content, .App__content, .App,
/* For credits. */
.CreditsModalContent
{
  user-select: text;
}

これで、マウスのドラッグやCtrl-Aで以下のようにテキストが選択でき、当然ながらCtrl-Cでクリップボードにコピーできるようになった。

Spotifyアプリからテキストをコピーできるようにした。(全選択した状態)

なお、サイドバーと下部のプレイヤー制御部が選択されていないが、別の要素のためのようで、どちらかの部分でCtrl-Aを押すと選択できる。

なお、思い付き+勢いでやってみたため、ちょっと不便なことがある。ボタンなどの余計なテキストも選択され、また、曲一覧の部分では思った部分がなかなかマウスで選択できず、特定の曲の選択が難しいのだ。これはHTMLの作り(JSで設定されたdraggable属性はCSSでは解除できない)と僕の未熟さのせいで、基本的にはちゃんとできるはずだ。

あと、全然見ない(ので忘れて居た)のと、一応 日本での取り扱い状況を尊重して、歌詞をコピーできるようにはしていない。

 

実際に使うか使わないかは別として、「(クソみたいな制限なんてせず、)できるものはできるままにしておく」ってのが僕の主義なので やってみた。

  •  0
  •  1

昔に比べていろいろ改悪された、現行版Spotifyアプリ(Linux版)。かなり嫌なのは、再生中にアイコン(以下、再生中アイコン)が ちらちら動き続けて目障りなことだ(→ 画像: 1曲目の緑の棒グラフのようなアイコン)。たまたま今日 アプリが更新されたので試したが、やっぱり変わっていなかった。それで、以前どこかのページで知った情報を思い出して、無理矢理アイコンを換えられないものかと試したらできた

試したアプリのバージョンは、 1:1.1.68.632.g2b11de83 である。※

※アプリでは出せないので、 aptitude show spotify-client コマンドで表示した。

概要(ポイント)は以下のとおり。

  • SpotifyアプリのUIは /usr/share/spotify/Apps/xpui.spa (以下、UIファイル)の中に入っている。
  • 再生中アイコンはUIファイルの中の images/equaliser-animated-green.gif で、24x24pxのアニメGIF
  • UIファイル(xpui.spa)はZIPファイルなので、問題のアイコンのファイルを交換して作り直せば良い。

再生中アイコンを置換する手順の例は以下のとおり。

  1. UIファイル(/usr/share/spotify/Apps/xpui.spa)を展開する。
    1. cd ~/tmp
    2. mkdir -p sp-xpui-work/xpui
    3. cd sp-xpui-work
    4. ln -s /usr/share/spotify/Apps/xpui.spa xpui.zip
    5. cd xpui
    6. unzip ../xpui.zip
  2. 展開したディレクトリ中の再生中アイコン images/equaliser-animated-green.gif を適当なものに交換する。
    • 条件: ファイル名はequaliser-animated-green.gif, GIF形式, 24x24pxであること。
      • ファイル形式はPNGでもいいかも知れないが、SVGは駄目だった。
    • アプリに合わせて、背景は暗く(黒系)、描画色は白などが良い。
  3. 新しいUIファイルを作る。
    1. zip -r ../xpui-new.zip *
  4. 新しいUIファイルを/usr/share/spotify/Apps/に置く。
    1. cd /usr/share/spotify/Apps
    2. sudo mv -i xpui.spa{,.orig}
    3. sudo cp -i ~/tmp/sp-xpui-work/xpui-new.zip xpui.spa

アイコンは既存のものでも構わないが、GIFで背景が暗い、丁度良いものがすぐには見付からなかったので、gimpで文字"♪"(サイズ: 22pxくらい)でテキトーに作った

面倒なのは、アプリが更新されるたびにアイコン置換作業をしなくてはならないことだが、自動化できそうだ。

この手順(以前のアプリでも同様)でUIをいろいろ改造できそうだが、まだ良く見ていない。 → ちょっと見たら、JSは判読困難なので改造は難しそうだが、CSSなら何とかできるかも知れない。: 例えば、緑で気に入らない再生中の曲の文字の色を変えるのはできるかも。 → 思い付いた。標準の色遣い(テーマ)が暗くて嫌いなので、つい、ライトテーマを作りたくなるが、まあ、それは やり過ぎってものだw (9/23 11:33)

「やり過ぎ」と書きつつも調べたら、(Linux版)SpotifyアプリのUIは(以前の予想どおり)基本的にブラウザ版と同じようで、ブラウザのWeb Developer Toolsを使えば、下のように(難読化を解除して)要素が調べられ、ちょっと変えて試すことができそうだ。 (9/23 11:52)

ブラウザ版で再生中アイコンの元(URL)を調べた。

→ (9/24 15:37) 「ちょっと」試したが、挫けた。UIファイル(xpui.spa)中のCSS(xpui.css, vendor-xpui.css)の色を変えて明るくしてみたら、(テキトーにやった割には)結構うまく行き、これなら(もっとちゃんとやれば)行けそうだと思ったのだが、表示内容(例: Daily Mix)によってはウインドウ(曲リスト)の半分だけ暗くなってしまった

更に調べたら、JS(xpui.js, vendor-xpui.js)の中でも色を設定していた。しかも、(難読化のせいかも知れないが、)同じ色の値が何度何度も書いてあって、なんとも腐っているサイコーなこと・・・ 素人かな? まあ、ツールで作ったりすると良くありそうな感じだが、なかなか付き合い切れない。

ただ、明るいテーマは なかなか爽やかで僕好みで捨て難い。が、苦労して色を変えても、アプリの更新で お釈迦になる可能性が高いので、あるアプリなりウインドウの色を実行時に変えるようなプログラムで色を変えたいが、そういうものはあるのだろうか?

↑ 色をグラデーションにしているので、単純な色の置換(LUT)では無理そうだ。 (9/24 17:33)

→ (9/24 19:17-9/25 12:30) 更に調べていたら、spicetify-cliというプログラムでテーマを変更できることが分かった。想像だが、これは上で僕がやったようにSpotifyのUIを展開して改造し、容易にカスタマイズできるようにているのだろう。デフォルトは(今は なき)GPMに似ていて懐かしい。

それで早速、僕のデスクトップのテーマ(Mint-X-Sand)に近付けてみた(spicetifyの古い版(1.2.1)は以前のSpotifyに対応しているので、そっちに適用した)。調整が不充分で見にくい箇所があるのと、ちょっと素っ気ないが(→ 調整し、テーマ(CSS)にも手を入れて随分改良した)、暗いよりずっといい。このプログラムは使い方のドキュメントが少ないが、いろいろ使えそうだ。

(9/26 7:09) 確かにspicetifyは使えるんだけど、Spotify同様なかなか余計なことをしてくれる。デフォルトはSpotifyのテーマを明るくするだけでいいのに、作者の好みで いろいろ変えてしまって(余程GPMに近くしたかったのか?: 個人的には、細かいところが「これは ないだろう」レベル)、それを戻すのに苦労した。まあ、苦手・嫌いなCSSの勉強(というか 付け焼き)には なったかなw

 

アイコンの交換は成功したものの、現行版には移らない。これはまあ、ちょっと思い付いたからやった、暇つぶしのお遊びだw

というのは、確かに以前は効かなかった、前・後ページのショートカットキー(Alt+←/→)が前の版で直ったが、依然として検索などで日本語が入力できないし(これは古い版でも同様)、左ペインでプレイリスト一覧がごちゃついているのが気に入らないからだ。それらが直ればいいが、まあ無理だろう。他に良くない点(例: 音が悪い)がなければ、百歩譲ってそれらを我慢して移行するのもありかも知れない。が、特にいいことはなさそうなので、古い版が動かなくなってからでも良さそうだからだ。

 

(9/23 5:12 画像を改良, わずかに加筆・修正, 9/23 9:48 わずかに加筆・修正, 9/23 11:33, 11:52 少し加筆, 9/23 16:07 PSに加筆して まとめとした。)

  •  0
  •  0