以前見かけて欲しかった魚の形をしたビンのワインも売っていたので買ってしまった。(今朝になって撮影)インポート食品が充実していると聞くと、高級な感じがするが、野菜やお肉が高いわけではない。野菜を地元の農家から調達したり、お肉は一頭買いをするなど、流通のコストを下げることで、値段を安くしている。ゆず、大根、豚肉が安かったので、ワインと一緒に買った。お肉など、普通に考えれば、映画を見た後で買うべきだろう。食料品は、一番いいものを買いたいので、できる限り早めに選びたい。映画を見終わった後では、お買い得品がなくなってしまうかもしれない。こんな時は地下1Fのエレベータ近くにある「冷蔵ロッカー」が使える。そのものズバリ、冷蔵庫の機能がロッカーについており、野菜やお肉を冷やしながらしまっておく事ができる。早めに行って映画のチケット購入後、空き時間にヤオコーで買い物をして、冷蔵ロッカーに保管。映画が終わったら、取り出して帰宅。使用には500円玉が必要だが、使用後、お金は戻ってくる。いつのまにか有料200円になっていた。先日ひさしぶりに冷蔵ロッカーを使ったら、有料200円になっていた。徐々に使用率が上がっていって、しまいにはほぼ常時使用中状態になり、使いにくくなっていた。有料になったら、使う人が急に減ったようでガラ空き状態。使いやすくなったけど、これで良いのかな...。カッチョいいもの、高級なものが入手可能でありつつ、生活必需品が無駄に高いということはない。ヤオコーの前は、大丸が入っていた。大丸もカッチョいいものや高級なものは充実していたが、どれも値段が高かったのだ。ヤオコーは「インスタ映えするプチ贅沢」と「日常生活」の両方のニーズを満たそうとしている。冷蔵ロッカーというサービスは、利用者の立場を熟知したサービスと言えるだろう。次に映画を見に行く時も、ヤオコーで買い物をしようと思った。キャリー・フィッシャー(レイヤ姫)の遺作になってしまった、スターウォーズ8作目「最後のジェダイ」を見てきた。このトリロジーの主人公であるレイをはじめ、レイヤ姫その他、女性の登場人物が特に多かったと感じる。若い娘ばかりではなく、大人の女性も多かった。直感的で行動的なパイロットを、冷静かつ厳しい態度で抑えていたのも、そのような女性達だった。(その厳しい事を言っていた者も、仲間を守るために、最後に衝動的とも思える行動に出るのだが...)そんな感じなので、女性が見ても楽しめる映画になっていたと思う。多少残念に思えたのは、反乱軍の旗艦?レイヤ姫がいる宇宙船の事を「クルーザー」と訳していた。「巡洋艦」としたほうが重厚で軍艦っぽい。スターウオーズシリーズでは、「プロトン魚雷」とか、日本語っぽい名前の兵器もあるのだから。映画XZをマルチスレッドで圧縮・展開もう、多くの人がweb上で紹介しているが、xzのver5.2以降はマルチスレッド圧縮に対応している。実は私も、今年になって、Zesty(17.04)用のxz-utils,liblzma-devパッケージをXenial(16.04)にインストールして使っている。packageページからバイナリパッケージを落としてきて、インストールしたがもっといい方法が紹介されていた。xzをマルチスレッドにしたら爆速になったaptの設定を書き換えて、一部のパッケージのみZestyのものが優先されるようにしている。これが正しいやり方だろう。私は、自家製xzランダムアクセスアプリのためにliblzma-devも使っているので、/etc/apt/preferences.d/xzを以下のようにした。Zestyはリポジトリ上から無くなった。そのため、この手法は使えなくなった。)さらに、xzイメージをマウントするためにnbdkitやnbd-clientもZestyのものを使っているので、以下の内容で/etc/apt/preferences.d/nbdを作った。Zestyはリポジトリ上から無くなった。そのため、この手法は使えなくなった。)圧縮をマルチスレッドで行うのは、多くのページで紹介されているように、xzのオプションに"-T"でスレッド数指定すればいい。"-T0"を指定すると自動でCPU数になるので、馬鹿の一つ覚え的に使うなら、"-T0"が良いだろう。古い方の圧縮イメージのマウントでも少し触れたが、私は、圧縮プリセットレベルをあえて0、ブロックサイズを1MiBに指定している。(しばしば、プリセットレベルを"0e"にすることもある)すなわち、以下のようなコマンドになる。xxxxxプリセットレベルを上げても圧縮レートの向上はわずかだ。それでいて必要な時間はぐっと長くなる。処理能力にもよるが、自分にあった使い方を探すのが良い。ここでも少し書いたが、現時点でxz-utilsでは、圧縮はマルチスレッドで行えるが、展開はマルチスレッドではできない。圧縮のほうが時間がかかるので、圧縮が高速化されるだけでもありがたい事だが、人間の欲望は際限がない。できれば展開も爆速にしたい。自家製のxzランダムアクセスアプリは、展開もマルチスレッドで行える。参照)これを使って、大きな.tar.xzを展開するなら、以下のようにする。-(tarの"v"オプションを省くと、展開中のファイル名が抑制されてさらに高速化する)ただし、このアプリは元々ランダムアクセス用に作ったので、パイプで展開処理できない。別の言い方をすると、圧縮データを標準入力から入れる事はできない。以下のような使い方はできない。これについては、本家での開発を待とう。なっている(以前の訳から少し直した)。xzrdのようなデコーダは、複数のストリームに対応しなければならないのだ。現時点でxzrdは、複数のストリームに対応していない。これについては、早急に対応しようと思っている。読んだら、"SHOULD"は、「する必要がある。」ぐらいの意味で、「しなければならない。」という意味ではない。本当におっちょこちょいだな。17.04)は、リポジトリ上から無くなったようだ。そのため、Zestyのもので置き換えることはできなくなった。しても新しい物を使うなら、ArtfulやBionicのもので置き換えるか、ソースからビルドする必要がある。xz関連はBionicのものでもinstallできるが、ndb関連は依存関係が解決できず、installできない。気が向いたら、詳しく調べるかもしれない。太郎」と言ったのが、いい意味で衝撃的だった。太郎」を気に入っている。一ヶ月後ぐらいに数カ月後、名前募集のニュースになった時も、またその映像が流れた(その日も複数のニュースで流れた)。太郎」の映像が流れた。ここまで何度も流れる事を考えると、NHKも気に入っているのかな?視聴者からの要望かな?本人、ピン太郎自身も、今でもピンク色だし。名前募集のニュースは数カ月後だった。そもそも、もう半年も経ったのかという感じで、時間の感覚がおかしい。圧縮データをランダムアクセスしようCFカードやSDカードのイメージならば、圧縮イメージをマウントするを応用して、loopデバイスをアクセスすれば、ランダムアクセスができる(もちろんreadonlyだけど)。元がストレージメディアのイメージなら、それでも良いだろう。続くストリームデータ(個人的には地震データ)を圧縮していることも多い。これらをアクセスするときでも、nbdkitとnbd-clientを使ってloopデバイスを作るのは、なんか手間が多い。手軽に、圧縮データ内の任意の位置を、高速にランダムアクセスしたい。utilsには、その機能が無い。ファイルフォーマット自体はランダムアクセスを提供できる構造になっているのだが、それを利用するためのアプリケーションは提供されていないのだ。個人的にはどうしても欲しかったので、数年前に自分で作ってしまった。本日、コメントやヘルプメッセージを少し整理して、ソースコードを以下に置いた。xzrd-20171215.tar.xzxzrd-20171219.tar.xz実は、「圧縮イメージをマウントする」をブログに書く前に実験的にそのアプリを実装しており、そのアプリを元に自分でnbdデバイスを作ろうとして、すでに存在しているのを発見し、ブログの記事になったのだった。自分で作ったアプリは、簡単な動作確認をしていたものの、実験的に作ったものだ。充分に検証されたわけではない。そのため、その時はブログでは紹介しなかった。最初に「圧縮イメージをマウントする」を書いた頃は、マウントできれば充分だと思っていたのだが、ちょっと見るだけでも複数のコマンドを発行しなければならないのは手間が多いので、ストレージメディアイメージではない圧縮データのランダムアクセスでは、実験的に作ったそのアプリを使っていた。2年半にわたって使用してきたが、特に問題が見られないので、公開することにした。(先週、Lubuntu1604用のマウント方法をブログに書いたついでに。)作った後で、liblzmaはマルチスレッドでも動作するのではないかと思い、マルチスレッド化した。プロセッサ数や圧縮レートにもよるが、マルチスレッド展開はとても速く、ランダムアクセス以外でも便利に使える。ランダムアクセス用に作ったため、indexテーブルを必要とするためだ。圧縮イメージをマウントすると同様、ランダムアクセス(およびマルチスレッド展開)のためには、小さなブロック単位で圧縮されていないと意味がない。マルチスレッド化に関しては、本家xz-utilsでも着々と開発が進んでいる。私がxzrdを実装した頃は、これら情報がなかったためIndexテーブルを使ったが、将来本家からマルチスレッド展開機能が出てくるときは、これらのフィールドを使用したものになるだろう。パイプで処理したい人はもう少し待つ必要がある。utilsのソースは、ソースファイル毎にライセンスが違っている。参照)本ソフトウエアは、xzのソースをベースに、一部コードを流用して作製した。公開の義務は無いと言える。私はxz圧縮の恩恵をたくさん受けているので、同じように公開する事にした。ビルド方法liblzmaを使うので、例えばDebian系であれば、liblzma-devパッケージをインストールしておく。中で、makeを実行する。パスの通った任意のディレクトリにコピーして使え。<fileName>DESCRIPTION指定されたファイル名の.xzファイルの非圧縮時のデータを、指定されたブロックサイズ、先頭ブロック番号、ブロック数で読み取る。読み取られたブロックは標準出力に出力される。.xzファイルは1つしか使えない。複数のストリームを持つxzファイルを正しく扱えない。ブロックサイズをバイト数で指定する。デフォルトは512だ。ここでいうブロックは、.xzファイルのストリーム内にあるブロックとは関係ない。ブロックデバイスのイメージを扱うときに、ブロック単位でアクセスしたいので、アクセスサイズが指定できるようにした。任意の値を指定できる。バイト単位でアクセスしたいなら、1を指定しても良い。読み取る先頭ブロック番号を指定する。読み取るブロック数を指定する。0を指定すると、最後まで読む。