Archive for the ‘日記’ Category

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

以前から、手持ちの音楽のファイル全部を(ローカルなHDD以外に)クラウドストレージにもバックアップしたいと思って居たが※、データ量が大きくて(800GB近い)料金がかさむので、貴重なものだけ(約130GB)に絞っていた。

※実は、そもそも その必要性には疑問がある。CDなどを買えば再び手に入るものをバックアップすることに意味があるかだ。ただ、仮に全部消失した場合、再び買って揃えるにはお金も手間も掛かるし、CDだったらPCに復旧(リッピング)させるには相当な手間が要り、その気力は起こらないだろうから、それが不要になる点では意味がある。

ただ、全部消失するような事態になったら、バックアップがあったとしても復旧させる気が起こるかは疑問だ。だから、ストレージの料金をなるべく安くし、無駄だったとしても「保険」として割り切れるようにしたい。

あるいは、「いかにも」だが、仮にバックアップする意味は全くなかったとしても、こういう技術の知識・経験が得られる価値はある。

それから、音楽以外にビデオのファイルもバックアップできればいいが、さすがにデータ量が桁違いに大きい(約3TB)から料金がかさむだろうし、随分前から そういうビデオを観る(観た)ことがないので、「消失したら諦める」で良いと考えている。

その後、変更やダウンロードが高く付くなど使い方に制限はあるものの料金の安い、archive(またはnear line) storageというカテゴリ(貯金で言えば、利率は高いものの、ATM手数料が高く、最短解約期間制限のある定期のようなもの。国債のほうが近いかも)があることを知り、それを試してみようと思って居た。面倒だったのと別件がいろいろあったので延期していたが、昨日から試し始めた。

まず、料金の安い いくつかのサービスの料金を比較した。

  • Microsoft Azure Blob Storage (以下、Azure(クラスはArchive)。他も同)
    • Archiveの料金: USD 0.00099/GB/月〜 (サーバの場所によって異なる。Googleも同じ)
      • 例: 500GBの場合、約USD 約0.50/月, 800GBの場合、約USD 約0.79/月 (アクセス関連の料金は含まない。以下同)
    • データ取得時間: 最大15時間
  • Google Cloud Storage (以下、GCS)
    • Archiveの料金: USD 0.0012/GB/月〜
      • 例: 500GBの場合、USD 0.60/月, 800GBの場合、約USD 0.96/月
    • データ取得時間: 1秒未満 ("sub-second")
  • Amazon S3 (以下、S3)
    • Glacier Deep Archiveの料金: USD 0.00099/GB/月〜
      • 例: 500GBの場合、約USD 約0.50/月, 800GBの場合、約USD 約0.79/月
    • データ取得時間: 12時間以内
  • [比較] Backblaze B2 Cloud Storage (archiveではない。以下、B2)
    • 料金: USD 0.005/GB/月
      • 例: 500GBの場合、USD 2.5/月, 800GBの場合、USD 4.0/月

※データ取得時間は下の「補足・訂正」の記載時に追加した。

それらのうち、バックアップに使う予定のソフト(rclone)が対応していて最安と思われる、AzureとGCSを試すことにした。

なお、S3の料金は、以前調べた時(高い地域を見たようだ)はUSD 0.002/GB/月だったので却下したのだが、今調べると(例えばオレゴンは)Azure並みなので、追って再検討したい。

同じく、以前は気付かなかったS3のIntelligent-Tiering(アクセス頻度で自動でストレージのクラス(→ コスト)を変える)が なかなか良さそうで、理想的に働けば(そうは問屋が許さなそうだが)、B2から全部移行しても料金を節約できるかも知れない。

一方、すぐに分かったS3の欠点は、AzureやGCSのような無料試用額・期間(例: GCSは約3万円, 90日)がないことだ。これは結構大きく、料金システムが複雑で簡単には見積もれないことと相まって、気軽には試せない。やっぱりAmazonはセコいのかね。

→ 下の「補足・訂正」に書いたように、S3はAzure同様データ取得時間が長いのと、他と異なって無料で気軽に試用できないため、見送ることにした。 (17:53)

上記のように、現在使っているB2に比べて料金が1/5前後と かなり安いから、うまく使えれば行けそうだ。また、Azure(S3も)はGCSより2割近く安く、(さまざまな疑念はあるがw)もし良ければ使うのも悪くはない。それに、Googleだって好きじゃないw

結論を先に書くと、Azureは全く論外だった。一番のポイントはストレージ内でファイル・ディレクトリの移動ができないことだ。(補足・訂正あり。下記参照) 例えば、ストレージに保存(バックアップ)する時に場所を間違えてしまったら直せないのだ。それから、保存後に気が変わっても移動できない。もちろん、コピーするか再度保存(アップロード)すればいいが、時間もお金も掛かる。

SMBならできるという情報もあったが、インターネットで使うものなのか?? TCP版があるのだろうか?

馬鹿馬鹿しい・面倒以前に、こういうファイルシステムの基本機能がなかったら使いものにならない。「安けりゃ いいってもんじゃない」の典型ではなかろうか。良く使う人が居るものだ。Azureに決める人(お偉いさんや客?)は そういうこと分からず、現場が苦しんでいるのかも知れない。もちろん、ストレージ以外に すごくいいことがあるのかも知れないが、どうだろうね・・・

一方、GCSはもちろんファイル・ディレクトリの移動ができる。当たり前のことだ。書くまでもないけど一応書いた。 (← 実は違っていた。下記参照)

ところが、書いたあとで別件(できればsym-linkもバックアップしたい)を思い出し、それに対応するためには別のバックアッププログラム duplicacyを使うことになり、それならファイルの移動は関係ないので、安いAzureが いいかも知れないので、まとまり次第、更新・追加する。 (11:29)

補足・訂正

その後、GCSもファイル・ディレクトリの移動はできないことが分かった。ディレクトリの移動はできず、ファイルの移動はサーバ内でのコピーと削除で実現されるので、Azureと同様だ。ただ、GCSは、Archiveでも高速にファイルにアクセス(取得)できるという大きなメリットがあることが分かった。Azureでは解凍(rehydrate)にものすごく時間が掛かる(30分どころではなく、「最大15時間」である)。S3は「12 時間以内」だ。まさに、待ってたら日が暮れる。

目的は保険的なバックアップなので、必ずしも高速に取得できる必要はないが、いつ使えるようになるのか分からないのでは不便だ。なので、GCSは少し高いけどその価値がありそうだ。

それにしても、GCSの高速性はどのように実現しているのだろうか。単に全部同じストレージ(HDD?)を使い、料金や最小保持期間でコストを回収しているのだろうか?

 

→ 結局、Azureは やっぱり使えないことが分かり、GCSが良さそうだという結論は変わらない。 (16:42)

また、rcloneとduplicacyの使い勝手や予想コストなどを比較し、sym-linkなどは当初は諦めてrcloneを使い、必要な時に対処することにした。 (17:48)

 

以下に、それぞれを試してのメモ・感想・気付いたことを示す。

Azure

  • 初期設定で いろいろ難しい単語・概念が出て来て複雑。
    • ストレージなのに仮想ネットとか言われてもねえ・・・
  • コンソール(web)が使いにくい・分かりにくい。
    • 日本語訳で更に悪くなっている。 → 少ししてから英語に切り替えて、ちょっとマシになった。
    • 機能が少な過ぎる。
      • ファイルの移動やコピーすらできない。
    • → StorageExplorer(Linux版)を試そうとするが、.NETのライブラリが要るようで、動かなかった。
      • 調べたら、それでもファイル・ディレクトリの移動はできないようだ。
    • ただし、Metrics(使用状況のグラフ表示)はGCSよりずっと使いやすい。
  • ファイルシステムの基本機能が不足している。
    • ファイル・ディレクトリの移動ができない。 ← 実装としてはGCSも同様だった。
    • ルートのファイル名に小文字しか使えない。 ← どうやら、これはGCSでの「バケット名」だったようで、GCSも同じだった。
  • 地域は、料金の安い westus2 (US西部)にした。
  • アップロード速度は悪くない。: 30Mbps以上出ていた。
  • ファイルの取得にものすごく時間が掛かる(仕様では最大15時間)。
  • 料金の更新は即時ではない。翌日? (当然か)
    • GCSも同じ。
  • 全般的に料金は安いが、Read操作が異常に高い(USD 5/10000ops)のが気になる。
    • これが いつどのくらい効くのか、今ひとつ分からない。

GCS

  • 初期設定は概ね分かりやすかった。
    • ただ、分からないので無設定(デフォルト)にした項目も結構あった。
  • コンソール(web)はAzureよりずっと使いやすい。
    • Azureよりずっと分かりやすく、使いやすかった。
      • ただし、他のGoocle Cloudのサービスで懲りているので、英語版で使った。
    • 機能は概ね充分だが、以下が不便だった。
      • (バケットなどの)ストレージのデータ使用量が分からないのは不便。。。
        • → rclone sizeで分かる。
      • プロジェクトの名前が変えられない? → 随分探してできた。
    • わずかに面倒なところがある。
      • 例: Monitoringのストレージの地域が最初は必ずデフォルトになり、設定してもリロードするとリセットされてしまう。
  • ファイルシステムの機能は普通・常識的で問題ない。
    • ディレクトリの移動はできない。
    • ファイルの移動は内部的にはコピーと削除になる。
  • 地域は、料金の安い us-west1 (オレゴン)にした。
    • 土地勘がないため、オレゴンは遅そうなイメージだったが、下記のように速度は問題なかった。
  • 全般的に料金は安いが、最小保存期間が365日と かなり長いのが気になる。
    • 大量のデータを短期間で消すと高く付きそうだ。
    • Azureは180日。
  • アップロード速度は悪くない。: 30Mbps以上出ていた。Azureより少し速かった。
  • ファイルの取得は高速。普通のストレージと同じ感覚で使える。
  • その他
    • 無料試用分(USD 300)を得るため、現在のGoogleのアカウントとは完全に別に作った。
      • 混同・誤用・クッキーなどのmixを避けるため、ブラウザも別にした。
      • アカウント登録時に電話番号が要る(SMSでの認証がある)ので困ったが、そろそろ解約かと思っていた楽天モバイルが使えた。
    • アクセスのための認証情報(パスワード)がなく、rcloneの設定でをどうするのか分からなかったが、最後にブラウザで認証・許可できることが分かった。
      • 先進的でちょっと感動したがw、rcloneのマニュアルに書いておいて欲しかった。
    • rcloneでのファイル・ディレクトリの移動に癖があるが、大きな問題はない。
      • サブコマンドmoveとmotvetoの違いなのだろう。

というわけで、無料試用分・期間(90日)一杯はGCSを試してみて、料金や使い勝手が問題なければ本格的に使うつもりだ。

 

PS. 予想もしていなかったのだが、「面倒で使えない奴」と烙印を押した楽天モバイルのSIMが、上記のようにGCSの認証に役に立った。今後も何かに使えそうなので、このまま残すのも悪くない気がしている。

PS2. 完全に個人的な意見なのだが、下に出ているページのアイコンを見るだけで、AzureとGCSは どちらも同じような色遣いなのに、いかにMicorsoftにセンス・美意識がないかを強く感じる。なんで四角、しかも正方形なんだろうかと思う。「1000%ない」と思う。

それだけじゃ見た目だけになるから追加すると、ページの説明にしたって、Azureは"Blob storage"(しかも、そのあとに「テキストデータ」と出て来る・・・)だが、GCSは"Object storage"と、明らかにGCSが正確で分かりやすい。

こういうところから、「MSはクソ過ぎて大っ嫌い、Googleは好きじゃない」という感想になるw

 

(19:27 修正・補足)

  •  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

2週間くらい前から、久し振りにドライブに行きたくなり、候補地は挙げていたものの天気や体調などが合わずに うだうだしていたが、昨日は珍しく「行けそう」な気分だったので行って来た。予定では、以前(2015年)も行ったことのある白河の関所跡に行き、途中で(、地図を見ていて見付けた)那須町の蓑沢(みのざわ)彼岸花公園に寄るつもりだった。※ ただ、何となく、体力が持たなくて彼岸花公園までで帰ることになる気はしていた。

※もちろん、彼岸花が好きとか観たかった訳ではなく、例によって たまたま目にしたからだけだ。関所跡にしても同様。まだ紅葉には早いので、行って歩くだけだ。

8:40頃出発した。通勤時間帯だったが、宇都宮を出てからは空いていて、気持ち良かった。外は涼しいが、車内は暑かった。ただ、冷房すると寒くなるが停めると暑くなり、0.5℃の温度刻みですら広く、オートエアコンなのに頻繁に設定を変えていた。もっとうまいエアコンはないものか。高い車のは もっと快適なのだろうか?

ただ、家のエアコンでも似たようなことをしているので、僕が贅沢なだけっていうオチの気はする。

車のマナーは概ね良くなかった(信号無視(赤になっても余裕で1-2台通る)、遅い車にぴったり つけて煽る、ちょっとしたところでウインカーを点けないなど)・・・

まあ、実際には駄目な連中が目立つだけで、平均すれば ちゃんとしているとは思うが、「いまだに ああいうのが居るのか」って感じで何とも情けなかった。

9:30頃、道の駅 きつれがわで休憩した。休んでいたら、以前来た時も掛かっていた、テーマソングらしき変な歌(というと失礼だが)が流れ出した。

なぜか、ここを出て少ししてから車内が煙草臭くなってしまって、なかなか抜けなかった。ヘビースモーカーの車が前に居たのだろうか。

10:30頃、生活の館 くろばねで休憩した。少し疲れて来た。また、例によって空腹かつ眠くなった。天気は良かった。

ここを出てすぐのところで、ネズミ捕りの準備をしていた。レーダー(可搬型オービス?)を設置したり距離を測ったりしていた。道の脇に ちょっとした駐車場(休憩・退避所?)的な場所があり、パトカー数種類や覆面らしき車も居て、なかなかフル装備な感じだった。珍しくて眺めたが、あと10分遅かったら捕まって居ただろう。田舎だけど一応国道(294号)だからなのかと思ったが、(あとで知ったが)今は交通安全週間なので、その関係なのかも知れない。

そう言えば、帰路に、(別の場所だと思うが)反対車線から ここらのタクシーにしてはあり得ないくらい遅いのが後ろに列を作っていたが、この関係かも知れない。

11:20頃、公園近くの駐車場の旧美野沢小学校跡に着いた。トイレに行きたかったが、(調べて知っていたとおり)なかった。小学校設備(例: 旗の台、鳥小屋、池、教室のOHPのスクリーン)は、僕が通っていた小中学校を思い出させた。廃校になって結構経っているのに、田舎のせいか全然荒れていなかった。まあ、こういう駐車場にしているから随時管理・整備しているせいか。

彼岸花の時期が ほぼ終わり、また、コロナの関係か「彼岸花まつり」は中止になったため、人はほとんど居なかった(駐車場の車は他に1台だけ、客は他に1組だけだった)が、静かで却って良かった。

確かに花の時期は過ぎていたが、遠目では赤が青空に映えて綺麗だった。あと、田んぼの黄緑も綺麗だった。こういうところに絵を描いたりするのだろう。でも、ああいうのは、見事だとは思うものの、人工的、あるいは、技術・技巧がメインになって居る感じなので余り好きではない。

余談: 建物の写真の水平が難しい。あとで調整または確認したつもりだが、特に最初の2枚は傾いて見える。基準とする線の見当の付け方が悪かったようだ。

 

ここまでの走りや ここでの散歩と景色に満足したし、予想どおり疲れたし、トイレにも行きたかったのでw、関所跡に行くのは止めて12時頃帰路に就いた。12:20頃、道の駅 伊王野でトイレと昼食にした(近くて良かった^^)。以前の会社の同僚に似た人を見たが、まあ別人だろう。髪型や顔の雰囲気や服装が随分似ていたが、平日にあんなところに居る訳がない。

妙なのは、たまに、家の近くで その人と同じ車種(「旧車」ではない程度に古い(R32の頃?)けど、結構速かったらしい)を見ることだ。やっぱり、その時間にそこに居る訳がないし、運転は荒く騒音は大きいから違うとは思う。昨日は その人に似た人が居たので、ハッとした。

高いせいか平日のせいか、昼時だけどレストランは空いていた。お腹が空いたのでカツカレーにした。1250円と高かった。当然、カツは揚げたてじゃないが、「まあ」おいしかった。意外にボリュームがあったようで、夕飯を軽くした。ただ、帰ってから服に油の臭いが残っていることに気付いて、あとからちょっと嫌な気分になった。

食券の自販機で前の老人が何やら困っていた。しばらく困って居たがギブアップして、後ろの僕に聞いて来たので教えた。どうやら、コインを入れるところが分からなかったようだ。ただ、質問が良く聞こえなかったので、本当にコインの投入口を聞かれているのか分からなかったが、勘で答えたら合っていた。

バリアフリーと思われる、コインを横に滑らせて入れる口は ある人にはバリアフリーでないようだ・・・ 昔の常識(縦長、銀色)と全然違う場所・入れ方・形・色だと、戸惑うのも仕方ない。文字で書いてあったのかも知れないが、老眼だと見えないのかも知れない。僕も、結構こういう感じで戸惑うことは多い。

帰り道に危ないワーゲン(ビートル。関係ないけど、車体が古かった: オリジナル版?)が居た。ほとんど常にセンターラインを踏むか はみ出して ふらふら走り、対向車が来ると急に戻るのを繰り返していた。遅くてイライラしそうだし、怖かったので別の道に逸れた。高齢者だろうか。

15:30頃、無事帰宅した。約145km, 約6.5時間。

気持ち良かったが、帰路で結構疲れが出て、帰ったら疲労困憊だった。なかなか体力が落ちている。室温は26.3℃と低いが、暑かった。

近頃は多いのだが、今回も運転中に ほとんど音楽を掛けなかった。まず、流れるだけで聴けないし、気が散るし、渋滞などの時に好きでない曲が掛かるとイライラするからだ。逆に、無音(エンジン+排気音、クラッチペダルのバネなどの音※、外の音)は結構いい。

※余りにもマニアックだが、普通の「ギリギリ」という感じの きしむ音もいいけど、たまにピアノのダンパーペダルを踏むか離す(= ダンパーが弦から離れる/に付く)時のような「シャーン」て音がして、それがなかなかいいのだ。それに、今気付いたが、クラッチペダルの加減の微妙さは、まさにダンパーペダルのそれに近いではないか。

 

相変わらず車の調子は良い。気になるのは、先日気付いたフロントガラスのフィルムの劣化程度(まだ運転には差し支えない)だ。劣化といえば、塗装は結構劣化しているが、自然なことなので気にならない。ただ、先日のディーラーのいい加減な作業のせいで左半分だけ艶が違うのは(注視しない限り分からないのと、そのうち戻るだろうとしても)、気に入らない。

帰りに久し振りにガソリンを入れた。久し振りのせいか値上がりのせいか5千円近くなったので、ちょっとびっくりした。買い物などでしか乗っていなかったので、燃費は12.4km/lと それほど良くなかった。それでも、買った時から全然落ちてない気がするのは すごいことだ。

(AQUOS sense liteで撮影。以降、記載しない限り同じ。)

  •  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
  •  0

音が耐えられないほど酷い。あのガラガラ音は芸術の対極で(要するに、綺麗でない・美しくない= キタナイ)、全く耐えられない。そして、排気ガスが余りにも臭い。これだけで すべてを台無しにする。乗って気分が悪くなろうが関係なく、ただ乗れればいい(= 実用車)ならいいが、その割には美しさを誇って高いものがあり、偉そうにしている気がする(乗用車の話)。

音という点では、昔のスバル(水平対向のドロドロ)も ひどかった。「なんでわざわざ あんな音を」と思っていたら、実は、排気管の取り回しの制約でそうなってしまって居た(しかも、そのために性能も落ちていた)だけだったことを知って、やっぱり**だと、改めて思った。

その点で最高なのは電気自動車だ。マジで。全然うるさくない(嫌な音がしない※)。「モーターのように」でなく、モーターそのものの滑らかな加速をする(はず ← 乗ったことないので)。

※実際には、モーターやその制御装置からの雑音(高周波音)があるだろうが、エンジンよりはずっといい。電車と同様だろう。

僕に言わせれば、真に美しいのは電気自動車だ。

もちろん、ハイブリッド車なんて論外だ。あれは妥協の産物、あくまでも繋ぎでしかない。僕にしてみれば、ガソリン車以下だ。でも、アイドリングストップがあるガソリン車よりはマシだろう。

かと言って、世界的な流行りになっている、ガソリン車から電動車への全面切り替えは、どうしたって無理だと思っている。どうやってオチを付けるのか、楽しみだ。

 

PS. ディーゼルで思い出した。フェリーはディーゼルなので排気が臭く、デッキに出ても海の上なのに爽やかでなくて(まあ、それでなくても海の風はべとつくが・・・)期待外れ・興ざめだった。結局、延々と室内に籠もっているしかない(籠るといっても大部屋で おもしろいことはなく、揺れて夜は眠れない)から、余り乗りたくない。

PS2. 全く関係ないが、エンジンで思い出したこと。: 例えば普通の4気筒のエンジンは、直列または並列4気筒と言われるが、本当はどっちなんだろうか? 置き方次第で直列にも並列にもなるってこと?? 個人的には直列が正しい気がするが、ちょっと はっきりさせて欲しい。

Wikipediaによれば、「直列」が正しいとのことで、「並列」はバイクでの俗称らしい。

  •  0
  •  0

先日、スマフォでWi-FiのAP一覧を見たら ちょっと驚いた。「****のiPhone」と、AP名に持ち主の名前(らしきもの)が出ていたのである。すっかり忘れて居るが、iPhoneの初期設定時に自分の名前を入れて何も変えずにテザリングモードにすると、そうなるのだろうか。

まあ、それが本名かは分からないが、本名だとすれは、近所に名前を撒き散らす訳で、セキュリティ的に余り良くないし(本名かどうかに関わらず、名前で興味を持って侵入しようとする輩が居そうだ)、不用心な気がする。例えば、ストーカーが在宅の確認に使うかも知れないではないか。あと、家だけじゃなくて、電車などでは近くに居るだけで名前がバレるかも知れない。※

※ただ、都会ではみんなテザリングしてそうなので(ポケットルータも山ほどあるし)、どれが誰の名前かは判別できない可能性が高い。それでも、目を付けた人のあとをつければ分かってしまう可能性もある。

以前問題になった「AirDrop痴漢」はBluetoothだろうが、似たような問題はあるだろう。

「だから、スマフォに名前を設定する時は良く考えよう。」というのは正しくない。というのは、設定した名前が どのように使われるかなんて、ユーザーは分からないからだ。だから、スマフォのソフト(OS)が、テザリングなどでのAP名を安易に付けないようにすべきだと思う。例えば、デフォルトでは乱数にして、初めてテザリングをonにする時に確認・変更させればいいのだ。※

※(普通に作ればそうするから)既にそうなっている気はするが、近頃は普通のことも まともにしないソフトが多いので、考え付いたことを書いた。

 

と書いていたら、最新のiOSでは名前に関する他の問題(まあ、「落とし穴」程度?)も見付かったようだ。しかも、スマフォに設定した名前でなくApple IDに登録した名前のようだ。安易に使ってる感じだねえ・・・ (9/27 5:00)

  •  1
  •  0

昔に比べていろいろ改悪された、現行版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