2017年12月31日日曜日

雪が降った。

2017年大晦日12:50頃、昼食後、録画しておいたTVを見ている時、何気なく外を見たら雪が降っているのに気がついた。

10分もしないうちに、止んでしまったけど。
投稿者 時刻: 0 件のコメント:

2017年12月24日日曜日

まだまだ使うぞ。水中ライト修理

フィリピンのセブのような南国の海であっても、20mも潜れば薄暗い。
日本国内であればなおさらだ。さらに、暗いとカメラのオートフォーカスがうまく機能しないこともある。そのため、水中ライトは必須だ。
最初の頃、いろいろな懐中電灯を試しが、最終的にPanasonic の BF-SG10 を長いこと使っている。
プロフィール写真の、浮いたカメラから垂れているのが、それだ。

今となっては明るさはいまいちだが、普通の電池で動作して、丈夫で軽い。
だいぶ古くなってきており、先週12/16(土)、井田へ行った時、潜る直前に壊れているのに気がついた。
壊れたものを持って潜ってもしょうがないので、その日は水中ライト無しで潜った。
帰宅後、壊れている箇所をよく見てみた。先端の黒いゴム製の部分が割れていた。

さらによく見てみると、この黒いゴムパーツはバンパーのようなもので、仮になかったとしてもライトの発光機能や防水機能は問題ない。すなわち、致命的な故障ではない。

なくても機能するとはいえ、バンパーなしで使っていたら、すぐに致命的故障に発展するだろう。修理することにした。
ウエットスーツを貼り合わせるためのゴムのりがあるので、それで貼りあわせてみた。


２ホゴで固定して、接着剤が固まるのを待った。まる一日置いて、2ホゴを剥がしてみると、接着剤はほとんど効いておらず、簡単に剥がれてしまった。
また、かなりゴムの劣化は進んでおり、仮に接着剤でくっついたとしても、次々に割れていくだろう。


購入は、2012年8月。もう５年も使っている。
この割れてしまったバンパーは破棄して、別にバンパーを用意したほうが良い気がしてきた。

近所のビバホームを物色していると、椅子や机の足のカバーで、良さそうなものが見つかった。

ライト先端の透明な部分の直径は35mm。カバーは32〜45mmなのでちょうと良いハズと思って買ってきた。
深すぎるので、少し切ることにする。

切る量が足らなかったので、さらに切り、底にも穴を開けた。

そして、かぶせてみたら…ガバガバ。結束バンドで縛ればなんとかなるが、ひどいガバガバ感だ。

というわけで、今度はもう少し小さいのを買ってきた。



切る線をペンで書いて、

クラフトナイフで切った。

多少歪んでいるが、とりあえずフィットしている。

最初に切ったガバガバのカバーを上からかぶせてみると、これまたぴったり入る。


これだけゴムを巻けば、バンパーとしては充分だろう。
解任するにはまだ早い。これからも頑張ってもらうぞ。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年12月23日土曜日

パルコのヤオコー

昨日、浦和パルコのUnited Cinemasで、「スターウォーズ/最後のジェダイ」を見たついでに、地下の「ヤオコー浦和パルコ店」で買い物をした。
過去になんだかんだで、「ヤオコー志木宗岡店」「ヤオコー草加原町店」「ヤオコーららぽーと富士見店」を使ったことがあり、近所にこんなお店があればなぁと思っていたところに、先月Openしたのだ。
デリが充実しており、お弁当やお惣菜がいろいろ選べる。食事の準備が嫌なときに助かる。
イートインのための場所も、普通のスーパーと比べて、なんかカッチョいい。ファストフード店のようだ。

インポート食品等も充実しており、様々な国のビールもある(フィリピンの「サンミゲル・ピルセン」もあった。懐かしい。)。
以前見かけて欲しかった魚の形をしたビンのワインも売っていたので買ってしまった。
(今朝になって撮影)


インポート食品が充実していると聞くと、高級な感じがするが、野菜やお肉が高いわけではない。
野菜を地元の農家から調達したり、お肉は一頭買いをするなど、流通のコストを下げることで、値段を安くしている。
ゆず、大根、豚肉が安かったので、ワインと一緒に買った。

特にお肉など、普通に考えれば、映画を見た後で買うべきだろう。
しかし、食料品は、一番いいものを買いたいので、できる限り早めに選びたい。
映画を見終わった後では、お買い得品がなくなってしまうかもしれない。

こんな時は地下１Fのエレベータ近くにある「冷蔵ロッカー」が使える。
そのものズバリ、冷蔵庫の機能がロッカーについており、野菜やお肉を冷やしながらしまっておく事ができる。
早めに行って映画のチケット購入後、空き時間にヤオコーで買い物をして、冷蔵ロッカーに保管。
映画が終わったら、取り出して帰宅。
使用には500円玉が必要だが、使用後、お金は戻ってくる。
2022/05/29(日) いつのまにか有料200円になっていた。
先日ひさしぶりに冷蔵ロッカーを使ったら、有料200円になっていた。
徐々に使用率が上がっていって、しまいにはほぼ常時使用中状態になり、使いにくくなっていた。
有料になったら、使う人が急に減ったようでガラ空き状態。
使いやすくなったけど、これで良いのかな…。
カッチョいいもの、高級なものが入手可能でありつつ、生活必需品が無駄に高いということはない。
ヤオコーの前は、大丸が入っていた。大丸もカッチョいいものや高級なものは充実していたが、どれも値段が高かったのだ。
ヤオコーは「インスタ映えするプチ贅沢」と「日常生活」の両方のニーズを満たそうとしている。
また、冷蔵ロッカーというサービスは、利用者の立場を熟知したサービスと言えるだろう。

次に映画を見に行く時も、ヤオコーで買い物をしようと思った。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年12月22日金曜日

スターウォーズ/最後のジェダイ を見てきた。

キャリー・フィッシャー(レイヤ姫)の遺作になってしまった、スターウォーズ８作目「最後のジェダイ」を見てきた。
このトリロジーの主人公であるレイをはじめ、レイヤ姫その他、女性の登場人物が特に多かったと感じる。
若い娘ばかりではなく、大人の女性も多かった。

直感的で行動的なパイロットを、冷静かつ厳しい態度で抑えていたのも、そのような女性達だった。
(その厳しい事を言っていた者も、仲間を守るために、最後に衝動的とも思える行動に出るのだが...)
そんな感じなので、女性が見ても楽しめる映画になっていたと思う。もちろん男が見ても面白い。

多少残念に思えたのは、反乱軍の旗艦？レイヤ姫がいる宇宙船の事を「クルーザー」と訳していた。むしろ「巡洋艦」としたほうが重厚で軍艦っぽい。
スターウオーズシリーズでは、「プロトン魚雷」とか、日本語っぽい名前の兵器もあるのだから。
投稿者 時刻: 0 件のコメント:
ラベル:

XZをマルチスレッドで圧縮・展開

もう、多くの人がweb上で紹介しているが、xzのver5.2以降はマルチスレッド圧縮に対応している。
実は私も、今年になって、Zesty(17.04)用のxz-utils,liblzma-devパッケージをXenial(16.04)にインストールして使っている。
私は無理やりこのUbuntu packageページからバイナリパッケージを落としてきて、インストールしたがもっといい方法が紹介されていた。

xzをマルチスレッドにしたら爆速になった

aptの設定を書き換えて、一部のパッケージのみZestyのものが優先されるようにしている。これが正しいやり方だろう。
私は、自家製xzランダムアクセスアプリのためにliblzma-devも使っているので、/etc/apt/preferences.d/xzを以下のようにした。
Package: *
Pin: release n=xenial
Pin-priority: 501

Package: xz-utils liblzma5 liblzma-dev
Pin: release n=zesty
Pin-Priority: 502
(2018/01/20 追記: Zestyはリポジトリ上から無くなった。そのため、この手法は使えなくなった。)

さらに、xzイメージをマウントするためにnbdkitやnbd-clientもZestyのものを使っているので、以下の内容で/etc/apt/preferences.d/nbdを作った。
Package: *
Pin: release n=xenial
Pin-priority: 501

Package: nbd-server nbd-client nbdkit nbdkit-plugin-*
Pin: release n=zesty
Pin-Priority: 502
(2018/01/20 追記: Zestyはリポジトリ上から無くなった。そのため、この手法は使えなくなった。)
圧縮をマルチスレッドで行うのは、多くのページで紹介されているように、xzのオプションに"-T"でスレッド数指定すればいい。
"-T0"を指定すると自動でCPU数になるので、馬鹿の一つ覚え的に使うなら、"-T0"が良いだろう。
古い方の圧縮イメージのマウントでも少し触れたが、私は、圧縮プリセットレベルをあえて0、ブロックサイズを1MiBに指定している。(しばしば、プリセットレベルを"0e"にすることもある)
すなわち、以下のようなコマンドになる。
xz -0e --block-size=1MiB xxxxx
プリセットレベルを上げても圧縮レートの向上はわずかだ。それでいて必要な時間はぐっと長くなる。
処理能力にもよるが、自分にあった使い方を探すのが良い。

ここでも少し書いたが、現時点でxz-utilsでは、圧縮はマルチスレッドで行えるが、展開はマルチスレッドではできない。
圧縮のほうが時間がかかるので、圧縮が高速化されるだけでもありがたい事だが、人間の欲望は際限がない。できれば展開も爆速にしたい。

自家製のxzランダムアクセスアプリは、展開もマルチスレッドで行える。
ソース: xzrd-171219.tar.xz (ビルド方法は、圧縮データをランダムアクセスしよう を参照)
これを使って、大きな.tar.xzを展開するなら、以下のようにする。
xzrd -c0 -v0 xxxxxxxx.tar.xz | tar -xvf -
(tarの"v"オプションを省くと、展開中のファイル名が抑制されてさらに高速化する)

ただし、このアプリは元々ランダムアクセス用に作ったので、パイプで展開処理できない。別の言い方をすると、圧縮データを標準入力から入れる事はできない。
すなわち、以下のような使い方はできない。
ssh user@host "tar -C work/ -xf - dddd/ | xz -T0 -0ecv --block-size=1MiB" | xzrd -c0 -v0 | tar -cvf -
ERROR: Need xz file.    <=== エラーになる。
これについては、本家での開発を待とう。
xz-file-format.txtの"2. Overall Structure of .xz File"を読むと、 
2. Overall Structure of .xz File

        A standalone .xz files consist of one or more Streams which may
        have Stream Padding between or after them:

            +========+================+========+================+
            | Stream | Stream Padding | Stream | Stream Padding | ...
            +========+================+========+================+

        The sizes of Stream and Stream Padding are always multiples
        of four bytes, thus the size of every valid .xz file MUST be
        a multiple of four bytes.

        While a typical file contains only one Stream and no Stream
        Padding, a decoder handling standalone .xz files SHOULD support
        files that have more than one Stream or Stream Padding.

        In contrast to standalone .xz files, when the .xz file format
        is used as an internal part of some other file format or
        communication protocol, it usually is expected that the decoder
        stops after the first Stream, and doesn't look for Stream
        Padding or possibly other Streams.
真ん中のあたり、 
        While a typical file contains only one Stream and no Stream
        Padding, a decoder handling standalone .xz files SHOULD support
        files that have more than one Stream or Stream Padding.
これを自分なりに日本語にすると、 
        一般的なファイルは、１つのストリームだけでストリームパディングが
        無いとはいえ、スタンドアロン.xzファイルを扱うデコーダは、１つ以上の
        ストリームやストリームパディングを持つファイルをサポートしなければ
        ならない。
となっている(以前の訳から少し直した)。
xzrdのようなデコーダは、複数のストリームに対応しなければならないのだ。
しかし、現時点でxzrdは、複数のストリームに対応していない。

これについては、早急に対応しようと思っている。
2017/12/23 追記 RFC-2119 をよく読んだら、"SHOULD"は、「する必要がある。」「やるべきだ。」ぐらいの意味で、「しなければならない。」という意味ではない。本当におっちょこちょいだな。
2018/01/20 追記 Zesty Zapus(Ubuntu 17.04)は、リポジトリ上から無くなったようだ。そのため、Zestyのもので置き換えることはできなくなった。どうしても新しい物を使うなら、ArtfulやBionicのもので置き換えるか、ソースからビルドする必要がある。xz関連はBionicのものでもinstallできるが、ndb関連は依存関係が解決できず、installできない。
気が向いたら、詳しく調べるかもしれない。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年12月20日水曜日

ピンク ピン太郎

半年前、シャンシャンが生まれたときに、NHKの夕方のニュース(それと、夜のニュースでも)で、新生パンダの名前をインタビューしている時に、小さな女の子が「ピンク ピン太郎」と言ったのが、いい意味で衝撃的だった。個人的には「ピンク ピン太郎」を気に入っている。

一ヶ月後ぐらいに数カ月後、名前募集のニュースになった時も、またその映像が流れた(その日も複数のニュースで流れた)。

昨日の一般公開のニュースでも、「ピンク ピン太郎」の映像が流れた。

ここまで何度も流れる事を考えると、NHKも気に入っているのかな？
視聴者からの要望かな？
本人、ピン太郎自身も、今でもピンク色だし。
2017/12/21 名前募集のニュースは数カ月後だった。そもそも、もう半年も経ったのかという感じで、時間の感覚がおかしい。
投稿者 時刻: 0 件のコメント:
ラベル:

2017年12月15日金曜日

圧縮データをランダムアクセスしよう

CFカードやSDカードのイメージならば、圧縮イメージをマウントするを応用して、loopデバイスをアクセスすれば、ランダムアクセスができる(もちろんreadonlyだけど)。

元がストレージメディアのイメージなら、それでも良いだろう。しかし、ダラダラと続くストリームデータ(個人的には地震データ)を圧縮していることも多い。これらをアクセスするときでも、nbdkitとnbd-clientを使ってloopデバイスを作るのは、なんか手間が多い。
もっと手軽に、圧縮データ内の任意の位置を、高速にランダムアクセスしたい。

しかしながら、xz utilsには、その機能が無い。ファイルフォーマット自体はランダムアクセスを提供できる構造になっているのだが、それを利用するためのアプリケーションは提供されていないのだ。

個人的にはどうしても欲しかったので、数年前に自分で作ってしまった。
本日、コメントやヘルプメッセージを少し整理して、ソースコードを以下に置いた。

xzrd-20171215.tar.xz
xzrd-20171219.tar.xz

実は、「圧縮イメージをマウントする」をブログに書く前に実験的にそのアプリを実装しており、そのアプリを元に自分でnbdデバイスを作ろうとして、すでに存在しているのを発見し、ブログの記事になったのだった。
自分で作ったアプリは、簡単な動作確認をしていたものの、実験的に作ったものだ。充分に検証されたわけではない。
そのため、その時はブログでは紹介しなかった。

最初に「圧縮イメージをマウントする」を書いた頃は、マウントできれば充分だと思っていたのだが、ちょっと見るだけでも複数のコマンドを発行しなければならないのは手間が多いので、ストレージメディアイメージではない圧縮データのランダムアクセスでは、実験的に作ったそのアプリを使っていた。
２年半にわたって使用してきたが、特に問題が見られないので、公開することにした。
(先週、Lubuntu1604用のマウント方法をブログに書いたついでに。)
作った後で、liblzmaはマルチスレッドでも動作するのではないかと思い、マルチスレッド化した。
プロセッサ数や圧縮レートにもよるが、マルチスレッド展開はとても速く、ランダムアクセス以外でも便利に使える。
ただし、パイプでは使えない。元々ランダムアクセス用に作ったため、indexテーブルを必要とするためだ。

また、圧縮イメージをマウントすると同様、ランダムアクセス(およびマルチスレッド展開)のためには、小さなブロック単位で圧縮されていないと意味がない。

マルチスレッド化に関しては、本家xz-utilsでも着々と開発が進んでいる。
xzの5.2以降では、Block header 内に、Compressed Size と、Uncompressed Size が入っている。
私がxzrdを実装した頃は、これら情報がなかったためIndexテーブルを使ったが、将来本家からマルチスレッド展開機能が出てくるときは、これらのフィールドを使用したものになるだろう。パイプで処理したい人はもう少し待つ必要がある。

xz utilsのソースは、ソースファイル毎にライセンスが違っている。
(tarの中の COPYING か、Debian系なら、/usr/share/doc/xz-utils/copyright を参照)
本ソフトウエアは、xzのソースをベースに、一部コードを流用して作製した。そして、xzのソースのライセンスは、public domain なので、公開の義務は無いと言える。しかし、私はxz圧縮の恩恵をたくさん受けているので、同じように公開する事にした。
ビルド方法
liblzmaを使うので、例えばDebian系であれば、liblzma-devパッケージをインストールしておく。
$ sudo apt-get install liblzma-dev
その後、ダウンロードしたソースを展開し、作成されたサブディレクトリ xzrd-20171219 の中で、makeを実行する。
$ tar -xf xzrd-20171219.tar.xz
  (サブディレクトリ xzrd-20171219 ができる)
$ cd xzrd-20171219
$ make
これで、サブディレクトリ xzrd-20171219 内に、実行ファイル xzrd ができる。
パスの通った任意のディレクトリにコピーして使え。

使い方
SYNOPSIS
xzrd [-h] [-b<blkSz>] [-o<blk#>] [-c<#OfBlk>] [-v<#>] [-T<#ofThread>] <fileName>

DESCRIPTION
指定されたファイル名の.xzファイルの非圧縮時のデータを、指定されたブロックサイズ、先頭ブロック番号、ブロック数で読み取る。 読み取られたブロックは標準出力に出力される。
.xzファイルは１つしか使えない。また、複数のストリームを持つxzファイルを正しく扱えない。

OPTIONS
-h ヘルプメッセージの表示
-b<blkSz> ブロックサイズをバイト数で指定する。デフォルトは512だ。
ここでいうブロックは、.xzファイルのストリーム内にあるブロックとは関係ない。ブロックデバイスのイメージを扱うときに、ブロック単位でアクセスしたいので、アクセスサイズが指定できるようにした。
任意の値を指定できる。バイト単位でアクセスしたいなら、1を指定しても良い。
-o<blk#> 読み取る先頭ブロック番号を指定する。
デフォルト=0。
-c<#OfBlk> 読み取るブロック数を指定する。0を指定すると、最後まで読む。
デフォルト=1。
-v<#> うるさいレベル。
0: 表示なし。
1: うるさい。
2: もっとうるさい。
3: もっともうるさい。
デフォルト=1。 (と言いつつ、0と0以外ぐらいしか違いがない)
-T<#ofThread> スレッド数を指定する。
省略時、または1よりも小さな値を指定すると、実装されているプロセッサ数が指定されたものと仮定される。
<fileName> .xz ファイルのファイル名を指定する。
おまけとして、xzrd-20171215.tar.xz内に、xz-file-format.txt の日本語訳途中の文書も入れておいた。xzファイルの構造がわかる程度の訳になっていると思う。 まだ途中なので、英文も併記されている。

公開したソースも、訳した文書も、Public domainのものとする。勝手に使っていいが、再利用の際は、
This software includes code from XZ Utils <http://tukaani.org/xz/>
を見えるようにしなければならない。また、引用元のxz-utilsのライセンスについての記述にしたがうこと。
私の名前は、見えなくても良い。再利用は、自己責任で行え。
履歴
日付 変更内容
2017/12/19 ソースコードをダウンロードするのに、GoogleDriveのアカウントが必要なようだったので、共有のリンクを作りなおした。
ヘルプメッセージの表示方法を「使い方」に書いていなかった。
さらにそのヘルプメッセージで、
"This software includes code from XZ Utils <http://tukaani.org/xz/>"
を表示するように、2017/12/15に改造したのに、改行文字を間違えて見えなくなっていた。
そして、xz-file-format.jp.txtの訳を少し直した。
リンクを貼り直したが、前のやつも残しておく。xzrd-20171215.tar.xz
修正内容が細かくたくさんあった。他にもありそうなので、履歴欄を作った。
どうにもこうにも、おっちょこちょいだな…
2017/12/20 各オプションのデフォルト値(省略時の値)を書き加えた。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年12月9日土曜日

Lubuntu 16.04 でｘｚ圧縮イメージをマウントする

Ubuntu 18.04では、この記事を参照。

最近ライフハック的な記事が多かったので、Linuxネタも入れておく。

Ubuntu12.04を使っている頃、「圧縮イメージをマウントする」で、xz圧縮されたHDDイメージをマウントする方法を書いていた。
しかしながら、この方法はLubuntu16.04では使えない(もちろんUbuntu16.04でも)。使えない理由は、
  • nbdの仕様が変更になり使い方が変わった。
  • Lubuntu16.04 xenial の nbdkitには(自分が見た限りでは)bugがあるようで動作しない。
ということだ。
これについて調べたのは、今年の１月だった。そのため、上記の「自分が見た限り」というのは、その時点のことだ。今は普通に動くのかもしれない。もし動かなかったら以下の方法に従え。

Lubuntu16.04でnbdkitを使って、xz圧縮イメージをマウントする方法を以下に示す(おそらくUbuntu16.04でも使える)。

新しいnbdkitをインストールする
Xenialのnbdkitにはbugがあるようで、どうしても動かなかった。
ネット上を探すと、開発者が英語で「とにかく動く！変な文句を言うな。」のような、かなり強い言い方で書いているのを見つけた(URLは失念 2018年1月再発見した)。そのnbdkitのバージョンがXenialのものよりも新しかったので、新しい物なら動くのではと考えた。
というわけで、試しにZestyのnbdkit、nbdkit-1.1.12-1build2をダウンロードしてインストールした。

以下のパッケージをダウンロードする。
nbdkit-plugin-dev_1.1.12-1build1_i386.deb
nbdkit-plugin-guestfs_1.1.12-1build1_i386.deb
nbdkit-plugin-libvirt_1.1.12-1build1_i386.deb
nbdkit-plugin-perl_1.1.12-1build1_i386.deb
nbdkit-plugin-python_1.1.12-1build1_i386.deb
nbdkit-plugin-ruby_1.1.12-1build1_i386.deb
nbdkit_1.1.12-1build1_i386.deb
適切なアーキテクチャ、適切なダウンロードサイトを選択してダウンロードせよ。
アーキテクチャ:amd64、山形大学のサイトからダウンロードするなら、以下のようにすると良い。
(山形大学は最近出来たミラーサイトで、速い。ありがたいことだ。) 
mkdir nbdkit
cd nbdkit
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit-plugin-dev_1.1.12-1build2_amd64.deb
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit-plugin-guestfs_1.1.12-1build2_amd64.deb
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit-plugin-libvirt_1.1.12-1build2_amd64.deb
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit-plugin-perl_1.1.12-1build2_amd64.deb
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit-plugin-python_1.1.12-1build2_amd64.deb
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit-plugin-ruby_1.1.12-1build2_amd64.deb
wget http://linux.yz.yamagata-u.ac.jp/pub/linux/ubuntu-archive/pool/universe/n/nbdkit/nbdkit_1.1.12-1build2_amd64.deb
ダウンロード後、それらをinstallする。 
sudo dpkg -i *.deb
nbdをexportする
以下のようにして、localhost(127.0.0.1)で、xzファイル SD8GB.img.xz をexport名 sd8g でexportする。
$ sudo nbdkit -n -e sd8g -i 127.0.0.1  xz file=SD8GB.img.xz
新しいnbdkitのexport方法は、oldstyle(昔ながらの方法)に加え、新しい方法newstyleがある。
newstyleでは、名前で公開を選択する使い方が提唱されている(と感じる)ので名前をつけて公開した。

長いオプション名--newstyle　は、何故か正常に動作しなかった。
短い名前のオプションのほうが、デバッグを含め多く利用されているであろうと考えて、短いオプションを使ったら動作した。

2020/08/01 追記: より新しいnbdkit(少なくともVersion 1.15.1)は、少しオプションが違う。上と同じことをするなら、以下のようになる。 
$ sudo nbdkit -n -e sd8g -i 127.0.0.1  --filter=xz file SD8GB.img.xz
bionicではnbdkitが提供されていないので、 https://github.com/libguestfs/nbdkit.git からソースを得て、自分でビルドして使う。ビルドの際にテスト段階でエラーになるが、ビルドはできておりxzマウントは正常に動作するので、そのままinstallすればとりあえず使える。
そういうのが嫌なら、focalではオフィシャルで提供されているので、bionicからfocalに移行してしまうのも良いかもしれない。
exportを確認する
newstyleでexportされていれば、ポート番号だけではなく名前でも見えるはずだ。
nbd-clientには、サーバがexportしている名前をリストすることができる。
以下のようにして行う。
$ nbd-client -l 127.0.0.1
Negotiation: ..
sd8g
nbdモジュールの読み込み
nbdはカーネルの機能であり、Lubuntu16.04(おそらくUbuntu16.04でも)では、モジュールとして提供されてる。しかし、デフォルトでは読み込まないので、読み込む必要がある。
さもなくば、nbd-client起動時に以下のようなエラーになる。
$ sudo nbd-client 127.0.0.1 /dev/nbd0 -name sd8g -b 512
Negotiation: ..size = 7671MB
Error: Cannot open NBD: No such file or directory
Please ensure the 'nbd' module is loaded.
Exiting.
以下のようにして、カーネルモジュール nbd.koを読み込む。 
$ sudo modprobe nbd
nbd-clientでデバイスノードを作成
上でも少し触れているが、以下のようにしてデバイスノードを作成する。
$ sudo nbd-client 127.0.0.1 /dev/nbd0 -name sd8g -b 512
Negotiation: ..size = 7671MB
bs=512, sz=8043626496 bytes

これで、デバイスノードができているはずだ。一応、確認する。
$ ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0  1月 27 14:33 /dev/nbd0
brw-rw---- 1 root disk 43, 1  1月 27 14:33 /dev/nbd0p1
ブロックデバイス全体を示すnbd0と、その中のパーティションnbd0p1ができている。
マウントする
ブロックデバイスができたのなら、後は普通に(とはいえreadonlyで)マウントすればいい。
$ mkdir xxx          <--- マウントポイント作成
$ sudo mount /dev/nbd0p1 xxx -o ro,uid=$USER,gid=$USER
マウントできるのだが、実は問題がある。
newstyleならば、本来は複数のイメージをexportできるはずなのだが、それができない。
また、--newstyle、--user、--group のような長いオプションも使えない。まだ実装の途中のように感じる。
そのため、約１年前に調べていたのに、blogでの公表はしなかった。

しばらく待てば、動くようになるかな？というような、希望的観測でいた。
しかし、ついさっき最新であるBionicのchangelogを見てみたが、何も変わっていないようだった。
以下は、その抜粋。
nbdkit (1.1.12-1build3) artful; urgency=medium

  * No-change rebuild for perl 5.26.0.

 -- Matthias Klose <doko@ubuntu.com>  Wed, 26 Jul 2017 20:11:33 +0000

nbdkit (1.1.12-1build2) zesty; urgency=medium

  * No-change rebuild for perl 5.24 transition

 -- Iain Lane <iain@orangesquash.org.uk>  Mon, 24 Oct 2016 10:35:54 +0100

nbdkit (1.1.12-1build1) yakkety; urgency=medium

  * Rebuild against libsystemd

 -- Gianfranco Costamagna <locutusofborg@debian.org>  Thu, 28 Jul 2016 15:56:37 +0200

nbdkit (1.1.12-1) unstable; urgency=medium

  * New upstream version
  * Bump Standards-Version
  * Add Vcs-* headers
  * Add nbdkit-plugin-ruby package

 -- Hilko Bengen <bengen@debian.org>  Tue, 21 Jun 2016 23:18:59 +0200

nbdkit (1.1.11-1) unstable; urgency=medium

  * New upstream version

 -- Hilko Bengen <bengen@debian.org>  Sun, 01 Nov 2015 11:46:37 +0100
:(以下省略)
待っているだけでは、だめかな…
おまけ：nbdkit-1.1.12のmanを自分なりに訳したものをgoogleドライブに置いた。
2017/12/10 マウント時のユーザ名の指定方法を、環境変数を使って行うようにした。ついでに解りにくい表現を整理した。「おまけ」を追加した。
2018/01/16 Linux kernel 4.13.0(Lubuntu1604 LTS enablement stackでの現在の最新カーネル)では、nbd-clientの引数に"-b 512"を追加する必要がある。
上記動作確認は、2017年1月ごろ、ポイントリリース前のLubuntu16.04のKernel 4.4.0で行っていた。SDカードは1セクタ=512Byteなので"-b 512"を指定する必要があることは解っていたが、実際には省略しても動作していたため、なるべく短い最低限の指定で動かす方法を書いた。多くのHDDやSDカードのブロックサイズは512(CD-ROMは違う)であり、そのように指定せずに動作していた事が間違いであり、以降のバージョンで逆戻りすることはないだろう。
また「とにかく動く！」的なことを言っていた文書も再発見したので、リンクを張った。見直すと書き込みが増えていた。１年前はホカホカの話題だったようだ。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年12月8日金曜日

ズボンの紐が抜けないようにする

私は、自他ともに認めるおっちょこちょいだ。
以前は、スエットズボンや海水パンツの紐を、うっかり引き抜いてしまうことがよくあった。
洗濯機から取り出すとき、他のものと一緒にもんたくって押し込んだ鞄から取り出すときなどだ。
途中で「あっ！」と気がついても時すでに遅し。紐の片方の端が入り込んでしまっていて、どうにもならない。
そうなってしまったら、紐通しで通すしか無い。
しかし、外出先で都合よく紐通しがあるなんて幸運は望めないだろうし、望むべきでもない。

そもそも抜けなければ良いのだ。
いろいろ考えて、今では紐の両端を結ぶ事で、抜けないようにしている。
輪っか状になるため端はなくなり、最悪入り込んだとしても、引っ張って戻すことができる。

しかし、輪っか状になってしまうと、結わえることができなくなる。
(結わえたとしても特殊な(変な)結び目になる)
これに対処するには下図のように、両端を結ぶ前に、一回ひねっておくとよい。

図のように両端を結ぶときは玉結びがいい。堅結びだと、ひねり部分と見分けがつかなくなることがあるためだ。
また、結んだ後で、100円ショップのほつれ止めで固めておけば、解けることはない。

たった１回ひねるだけで、普通に結ぶことができるようになる。
動画では、蝶結びにしている。

上の動画のスエットズボンは、もう１０年以上前に買ったものだ。
そのため、完全にゴムが死んでおり(紐も２回切れている)、紐無しでは使えない。
(冬しか使わないので、長生きしている)
かなり古いのだが、長期間使っていると、愛着が湧いてきてなかなか捨てられない。
思い起こせば、この方法を使うようになった最初のズボンだった。
2017/12/09 「ヒモ」を「紐」に変更。誤字修正(片結び->堅結び)。ついでに一部加筆＆修正。
投稿者 時刻: 4 件のコメント:
ラベル: , ,

2017年12月3日日曜日

Another way to fold the IKEA Poncho. もうひとつの IKEA レインポンチョのたたみ方。

IKEAレインポンチョのたたみ方で示した方法は、ポケットが引き出せないタイプのレインポンチョでは使えない。
それらポンチョでも使える方法を今回は示す。
実は、最初に思いついたのはこの方法だったのだが、説明がしにくく、途中でぐちゃぐちゃになりやすいので、試行錯誤の末、以前書いたこのたたみ方を編み出した。(何度も忘れてやり直しているうちに、徐々に洗練されていったのだ)
まずは、ポケットを出さずに、縦に細く折って、ポケットの口の高さから下を1/3の幅で２回折る。

折りたたんだ部分の上端が、「ポケットのふた」の裏側にくる。

折りたたんだ部分とポケットを一体と考えて、それらをまとめてひっくり返す。


ここまでくれば、後は以前の方法と同じだ。

実際に作業をしているところ。
お腹のポケットが引き出せない、貼り付いたタイプのポケット(アウトポケット？パッチポケット？)なら、この方法が使える。
IKEAのレインポンチョでも、縦に細く折りたたんだ状態でポケットを引き出すのを忘れていることに気がついた時に、この方法は使える。

2017/12/04 タイトルを直した。
投稿者 時刻: 2 件のコメント:
ラベル: , , , ,

2017年12月2日土曜日

フローリングで滑らない靴下

掃除が楽なので、フローリングで生活をしているが、冬は足が冷たい。
そのため、冬の間はヒートテック靴下を愛用している。

便利ではあるが、普通の綿の靴下よりも、滑るような気がする。
大男が、ツルッと滑ってひっくり返りでもしたら、大惨事間違い無しだ。
とはいえ、数年前にどっさり一括購入したので、使わないともったいない。

というわけで、それら靴下を、滑り止め改造する事にした。
なんかのバカ改造で少しだけ使用して、たくさん残っていた「バスボンド」を使う(これも使わないともったいない)。
これは、シリコンゴムなので耐候性も高く、洗濯しても問題ない。

改造対象の靴下： しばらく使用しているが、冬だけ使用なので、あまり傷んでいない。これを買い換えてしまうのは残念だろう。

あまり傷んでいないとはいえ、ある程度はこすれて、毛羽立っている部分がある。その部分に、シリコンゴムをつける。

靴下にバスボンドを塗布する際は、繊維に馴染むようにヘラでしっかりと、薄く均一に塗るのが良い。
このような作業をするときは、しっかりと固定して作業すると楽だ。
とはいえ、強く引っ張ってはいけない。マスキングテープで複数箇所を丁寧に固定する。
(だからって、床に固定するなんて…)

塗った量さにもよるだろうが、２時間もすれば、ゴム状になっている。
大掃除で、「バスボンド」や「バスコーク」を使って余っているなら、靴下に塗って使ってしまおう。

また、この「IKEAレインポンチョのたたみ方。」の動画を撮影している時に履いているような、短い靴下のかかと側の縁の内側に塗ると、かかとがずれにくくなる。
投稿者 時刻: 0 件のコメント:
ラベル: , , ,
登録: 投稿 (Atom)