2017年12月31日日曜日

雪が降った。

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

10分もしないうちに、止んでしまったけど。

2017年12月24日日曜日

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

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

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

帰宅後、壊れている箇所をよく見てみた。先端の黒いゴム製の部分が割れていた。

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

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


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


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

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

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

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

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

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



切る線をペンで書いて、

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

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

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


これだけゴムを巻けば、バンパーとしては充分だろう。
解任するにはまだ早い。これからも頑張ってもらうぞ。

2017年12月23日土曜日

パルコのヤオコー

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

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


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

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

こんな時は地下1Fのエレベータ近くにある「冷蔵ロッカー」が使える。
そのものズバリ、冷蔵庫の機能がロッカーについており、野菜やお肉を冷やしながらしまっておく事ができる。
早めに行って映画のチケット購入後、空き時間にヤオコーで買い物をして、冷蔵ロッカーに保管。
映画が終わったら、取り出して帰宅。
使用には500円玉が必要だが、使用後、お金は戻ってくる。
2022/05/29(日) いつのまにか有料200円になっていた。
先日ひさしぶりに冷蔵ロッカーを使ったら、有料200円になっていた。
徐々に使用率が上がっていって、しまいにはほぼ常時使用中状態になり、使いにくくなっていた。
有料になったら、使う人が急に減ったようでガラ空き状態。
使いやすくなったけど、これで良いのかな…。

カッチョいいもの、高級なものが入手可能でありつつ、生活必需品が無駄に高いということはない。
ヤオコーの前は、大丸が入っていた。大丸もカッチョいいものや高級なものは充実していたが、どれも値段が高かったのだ。
ヤオコーは「インスタ映えするプチ贅沢」と「日常生活」の両方のニーズを満たそうとしている。
また、冷蔵ロッカーというサービスは、利用者の立場を熟知したサービスと言えるだろう。

次に映画を見に行く時も、ヤオコーで買い物をしようと思った。

2017年12月22日金曜日

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

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

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

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

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.
これを自分なりに日本語にすると、
        一般的なファイルは、1つのストリームだけでストリームパディングが
        無いとはいえ、スタンドアロン.xzファイルを扱うデコーダは、1つ以上の
        ストリームやストリームパディングを持つファイルをサポートしなければ
        ならない。
となっている(以前の訳から少し直した)。
xzrdのようなデコーダは、複数のストリームに対応しなければならないのだ。
しかし、現時点でxzrdは、複数のストリームに対応していない。

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

2017年12月20日水曜日

ピンク ピン太郎

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

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

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

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

2017年12月15日金曜日

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

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

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

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

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

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

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

最初に「圧縮イメージをマウントする」を書いた頃は、マウントできれば充分だと思っていたのだが、ちょっと見るだけでも複数のコマンドを発行しなければならないのは手間が多いので、ストレージメディアイメージではない圧縮データのランダムアクセスでは、実験的に作ったそのアプリを使っていた。
2年半にわたって使用してきたが、特に問題が見られないので、公開することにした。
(先週、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ファイルは1つしか使えない。また、複数のストリームを持つ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 各オプションのデフォルト値(省略時の値)を書き加えた。

2017年12月9日土曜日

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

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

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

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

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 のような長いオプションも使えない。まだ実装の途中のように感じる。
そのため、約1年前に調べていたのに、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は違う)であり、そのように指定せずに動作していた事が間違いであり、以降のバージョンで逆戻りすることはないだろう。
また「とにかく動く!」的なことを言っていた文書も再発見したので、リンクを張った。見直すと書き込みが増えていた。1年前はホカホカの話題だったようだ。

2017年12月8日金曜日

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

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

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

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

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

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

上の動画のスエットズボンは、もう10年以上前に買ったものだ。
そのため、完全にゴムが死んでおり(紐も2回切れている)、紐無しでは使えない。
(冬しか使わないので、長生きしている)
かなり古いのだが、長期間使っていると、愛着が湧いてきてなかなか捨てられない。
思い起こせば、この方法を使うようになった最初のズボンだった。

2017/12/09 「ヒモ」を「紐」に変更。誤字修正(片結び->堅結び)。ついでに一部加筆&修正。

2017年12月3日日曜日

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

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

まずは、ポケットを出さずに、縦に細く折って、ポケットの口の高さから下を1/3の幅で2回折る。

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

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


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

実際に作業をしているところ。

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


2017/12/04 タイトルを直した。

2017年12月2日土曜日

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

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

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

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

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

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

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

塗った量さにもよるだろうが、2時間もすれば、ゴム状になっている。

大掃除で、「バスボンド」や「バスコーク」を使って余っているなら、靴下に塗って使ってしまおう。

また、この「IKEAレインポンチョのたたみ方。」の動画を撮影している時に履いているような、短い靴下のかかと側の縁の内側に塗ると、かかとがずれにくくなる。

2017年11月25日土曜日

無精ひげの一応日記

古い「無精ひげの一応日記」の魚拓が見つかった
訳あって、so-netブログをやめたのだが、その時にBackup等をしていなかったので、手元に記事は一切残っていない。
ソースコード、図面(というかマンガかな)、画像、写真などは、この作業をしている時に、見つかったのだが。

この記事では、「8年前に…」となっているが、魚拓の記事を見ると、もう11年も前だ。
この頃は、雑誌付録のマイコンボードではなく、市販のマイコンボードを使っていたかも。

当時は、2つの会社の仕事をしており、本当に忙しくて時間が取れず、早起きして20分、通勤時の電車の中で検討をしたり、PDF化した文書をガラケーで読んだり、帰宅後23時過ぎから30分の作業。
その繰り返しで、作業をしていたのだ。

集中して連続的に1日作業できれば、とても効率的だっただろう。しかし、連続作業時間は長くても30分。時にはWindows Updateだけで終わってしまうこともある。
(しかも、ものすごくおっちょこちょいだし。)
よくやったものだ。若いって素晴らしい。馬鹿いって素晴らしい?

2017年11月23日木曜日

ビルの解体現場

景気が良いのか、近所は建設ラッシュだ。
街なかにある、高度経済成長期に建てられたと思われる古いビルが解体されていた。
散歩中、すごい眺めだったので、撮影した。

背後に広がる雲と斜光のせいで、写真が世紀末的な雰囲気になってしまった。

記憶が正しければ、これは元々4階建てだった。


回りこむと奥に小さな重機が見える。
上から少しずつ解体するのだろう。大きな重機で手前を崩してスロープを作り、小さな重機で2階の高さに上り、上のほうを解体している。
大きな重機は重いので、床が抜けるかもしれない。そのため、上がるのは小さな重機なのだろう。
慎重かつ丁寧な解体だ。


小さい重機のアップ。

世紀末のような空の下で行われるビル解体。瓦礫の山と重機。
それだけ聞くと破滅的な印象だが、親子重機で丁寧に解体していた。
破壊ではなく、Scrap & Build による街の成長を感じた。

2017年11月18日土曜日

サイ引き埴輪

先日、よく晴れた日に、例のママチャリでサイクリングがてら、彩湖や秋ヶ瀬公園へ行ってきた。
紅葉は部分的には終わっており、部分的にはまだ早い。
ひとつの木でも、赤い葉もあれば、青々とした葉もある。
なんかいまいち。
寒くなったり、暖かくなったり、雨が降ったりで、紅葉の進み方もめちゃくちゃだ。

秋ヶ瀬公園から、プラザウエストへ行った。
大きな埴輪が展示されていた。

どう見ても、サイに見える。説明文を読んでみると...
犀形埴輪(復元)
別所沼古墳から発掘された6世紀頃の形象埴輪の破片のいくつかを調査した結果、特徴的な角などの部位と装飾品の玉などから、「さいたまB」の名称由来が動物のサイであることが判明しました。新たに発見された「犀(さい)形埴輪」の存在については何の目的で作られたのかなど、さいたまBの研究者の間で激しい議論が繰り返されました。実寸大で復元された飾り犀は、当時の武蔵の国の豊かな社会をうかがい知る事が出来る貴重な資料と言えます。
なんと!サイの形をした埴輪があるなんて!!
6世紀に、サイが関東にもいたの?


プラザウエストに行ったら、自分で巻くアイスクリームを食べる。
数カ月に1回しか行かないので、なかなかうまくできない。

いつかはうまくなるだろう。
時々、ブログに写真を上げることにする。

2017年11月10日金曜日

LibreOffice Draw でアニメーション作製 番外編

遊び心で、How to fold IKEA poncho. IKEAレインポンチョのたたみ方で作ったアニメーションのコマ数を増やして、動きをなめらかにした。
最後に折り目が勢い良く裏返る部分も、さらにコミカルな感じにしてみた。



もはや、解りやすさの追求ではなくなり、自己満足の領域に踏み入っている。
全くの無駄。何と言うバカ行為だろう。

とはいえ、遊びとは本来そういうものだ。儲けや効率を考えてやるのは仕事だ。
逆に、仕事に個人的な嗜好を持ち込むのも、間違っている。それは遊びだ。

特に、最後の折り目が裏返る部分が、なにか誤解を招くような表現になっている。
そのため、これを説明のアニメーションとして使うわけにはいかない。
アニメーション作製についての有用な情報もなく、メモとしても価値がないので、番外編とした。
実は、作製はだいぶ前だったのだが、今日まで公開しなかったのは、これらの理由による。

とはいえ、馬鹿なことをするのは、楽しいもんだ。
ジジイになったとき、ひたる思い出になるだろう。

2017年10月29日日曜日

NASのプリントサーバ機能をLinuxから使うのだ

以前、ここで示したプリンタ CANON LBP-1310を今でも使っている。
プリンタは母艦に接続してあり、ノートPCで印刷するときは、PDF化してから母艦にssh等で転送して印刷していた。
それでもあまり不便を感じていなかったが、NASにプリントサーバの機能があるんだから使ってみようと思った。

いきなりノートPCからNASに接続されているプリンタへ、ネットワークから印刷するのは、挑戦的なことが多すぎる。
順番に1つずつやっていく事にした。

USBでローカル接続して印刷できることを確認する
まずは、ノートPCのプリンタドライバその他が機能することを確認しておいたほうが良い。
実は、この作業はだいぶ前にやっていて、どうやったか具体的な事は、忘れてしまった。
過去に調べた内容を参考に作業したので、手動だったはずだ。
また、多くのUbuntu系は、デフォルトでCUPSが入っているが、Lubuntuには入っておらず、いろいろインストールするのに苦労したと記憶している。
ドライバのダウンロード場所: LIPS4 Printer Driver for Linux Ver.3.40(32bit & 64bit)
上記から、linux-lips4-drv-v340-jp.tar.gzをダウンロードして、展開するといろいろなファイルが入っている。
drwxrwxr-x devel/devel       0 2017-07-07 00:00 linux-lips4-drv-v340-jp/
drwxrwxr-x devel/devel       0 2017-07-07 00:00 linux-lips4-drv-v340-jp/Documents/
-rw-r--r-- devel/devel   86793 2017-07-07 00:00 linux-lips4-drv-v340-jp/Documents/README-lips4-3.4x.html
-rw-r--r-- devel/devel   27592 2017-07-07 00:00 linux-lips4-drv-v340-jp/Documents/LICENSE-JP.txt
-rw-r--r-- devel/devel  701906 2017-07-07 00:00 linux-lips4-drv-v340-jp/Documents/guide-lips4-3.4x.tar.gz
drwxrwxr-x devel/devel       0 2017-07-07 00:00 linux-lips4-drv-v340-jp/Sources/
-rw-rw-r-- devel/devel 20578343 2017-07-07 00:00 linux-lips4-drv-v340-jp/Sources/cndrvcups-common-3.80-1.tar.gz
-rw-rw-r-- devel/devel   616361 2017-07-07 00:00 linux-lips4-drv-v340-jp/Sources/cndrvcups-lips4-3.40-1.tar.gz
-rw-rw-r-- devel/devel   157057 2017-07-07 00:00 linux-lips4-drv-v340-jp/Sources/cndrvcups-utility-1.00-1.tar.gz
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/
-rw-r--r-- devel/devel     1979 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_ko_utf8.lc
-rw-r--r-- devel/devel     1974 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_es_utf8.lc
-rw-r--r-- devel/devel     2065 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_de_utf8.lc
-rw-r--r-- devel/devel     2134 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_ja_utf8.lc
-rw-r--r-- devel/devel     1696 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_zh_CN_utf8.lc
-rw-r--r-- devel/devel     2022 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_it_utf8.lc
-rw-r--r-- devel/devel     2055 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_fr_utf8.lc
-rw-r--r-- devel/devel     1693 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_zh_TW_utf8.lc
-rw-r--r-- devel/devel     1875 2017-07-07 00:00 linux-lips4-drv-v340-jp/resources/installer_en_utr8.lc
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/RPM/
-rw-r--r-- devel/devel   851343 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/RPM/cndrvcups-lips4-3.40-1.i386.rpm
-rw-r--r-- devel/devel 18607739 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/RPM/cndrvcups-common-3.80-1.i386.rpm
-rw-r--r-- devel/devel    61872 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/RPM/cndrvcups-utility-1.00-1.i386.rpm
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/Debian/
-rw-r--r-- devel/devel   585514 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/Debian/cndrvcups-lips4_3.40-1_i386.deb
-rw-r--r-- devel/devel   132182 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/Debian/cndrvcups-utility_1.00-1_i386.deb
-rw-r--r-- devel/devel 18619996 2017-07-07 00:00 linux-lips4-drv-v340-jp/32-bit_Driver/Debian/cndrvcups-common_3.80-1_i386.deb
-rwxr-xr-x devel/devel    12776 2017-07-07 00:00 linux-lips4-drv-v340-jp/install.sh
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/RPM/
-rw-r--r-- devel/devel    62549 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/RPM/cndrvcups-utility-1.00-1.x86_64.rpm
-rw-r--r-- devel/devel   878504 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/RPM/cndrvcups-lips4-3.40-1.x86_64.rpm
-rw-r--r-- devel/devel 18612741 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/RPM/cndrvcups-common-3.80-1.x86_64.rpm
drwxrwxr-x devel/devel        0 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/Debian/
-rw-r--r-- devel/devel 18626652 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/Debian/cndrvcups-common_3.80-1_amd64.deb
-rw-r--r-- devel/devel   595000 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/Debian/cndrvcups-lips4_3.40-1_amd64.deb
-rw-r--r-- devel/devel   132120 2017-07-07 00:00 linux-lips4-drv-v340-jp/64-bit_Driver/Debian/cndrvcups-utility_1.00-1_amd64.deb
install.shを実行すれば、うまく行ったように記憶している。
何気に重要だったのは、linux-lips4-drv-v340-jp/Documents/README-lips4-3.4x.html だ。
以前も自分のプリンタ用のドライバがどれか解り難かったが、今でもわかりにくい。

とにかくウチのプリンタ、LBP-1310は CNCUPSLBPSERIESLJ.ppd(以前と同じ)であることは間違いないが、謎の事が書いてある。
共通で使用できるドライバ
ドライバの印刷設定画面[デバイス設定]ページで、機種に対応する[デバイスの種類]を設定して使用してください。機種名の先頭にある[X]が[デバイスの種類]で設定する値を示しています。
この「機種名の先頭にある[X]が...」が、うちのプリンタ LBP-1310の場合、2 であることはわかるのだが、「設定してください」って言われても、どこで? 同文書内には、それ以上書の事はかれていない。
これは、linux-lips4-drv-v340-jp/Documents/guide-lips4-3.4x.tar.gz を展開した文書内に、書かれていたのだった。
(しかし、こっちの文書には、選択すべきドライバや、ドライバの種類に入力する数字が書いてない)
index.htmlをブラウザで開いて、「ドライバUIからの印刷設定」「[デバイス設定]ページ」と進むと、その「デバイスの種類」を入力する場所が書かれている。
ドライバインストール、および設定後に、cngplpコマンドを実行して、このデバイスの種類を2にセットする。

さすがにこの件については、メモが残されていた。
全部設定したら、テスト印刷をして動作の確認をする。


NASでプリントサーバを起動する
ウチではBuffaloのNASを使っている。WindowsPCではないので、管理アプリは使えないので、ブラウザから入って、プリントサーバをONにする。


他に設定するところはないし、NASの説明書を読んでも、それ以上の事は書いていない。
ここから先はどうやるんだ?

いよいよネットワーク経由で印刷する
ネットワークでプリンタを共有するにはいくつかの方法がある。
このNASの共有方法が、どうなのかがわからない。もちろん、上記でも示したが、説明書にも書いてない。

どうしたものかなどと悩んでいてもしょうがない。NASなんだからSMBじゃないかと考えて、"smbclient -L "で見ると、"lp"という名前でプリンタが見える。
$ smbclient -L XXX.XXX.XXX.XXX
WARNING: The "syslog" option is deprecated Enter xxxxxxx's password: Domain=[XXXXXX] OS=[Unix] Server=[Samba 3.6.XX-XX.xxxxxxx] Sharename Type Comment --------- ---- ------- lp Printer Network Printer for Windows info Disk LinkStation Utilities share Disk LinkStation folder IPC$ IPC IPC Service (LinkStation) : : (省略) :
(一部伏せ字)

というわけで、少なくともSMBでの共有ができるようだ。
また、その時の資源名も"lp"であることがわかった。

ネットワークプリンタの設定は、GUIでやってみる。
[システムツール]->[プリンター]でプリンタダイアログを表示して、「+追加」をクリックする。
「新しいプリンタ」ダイアログが表示される。
以下のように、IPアドレスと共有資源の名前を入力する。共有資源の名前は、上記のように"lp"だ。

2019年06月13日追記:
smbclientパッケージがインストールされていないと、「Samba経由のWindowsプリンタ」は表示されない。
表示されない場合、端末エミュレータから、以下を入力して、smbclientパッケージをインストールして、やり直せ。
sudo apt-get install smbclient

xxx.xxx.xxx.xxxは、IPアドレスをセットする。
「進む」ボタンを押す。

すると、次はドライバの選択になる
ここでは、"Canon"を選ぶ。

「進む」ボタンを押す。

ドライバがずらっと表示されるので、下の方の"LBP Black and White LIPS4"を選ぶ。
何を選べば良いのか極めてわかりにくいが、/usr/share/cups/model/CNCUPSLBPSERIESLJ.ppdの中身を見ると、"LBP Black and White LIPS4"であることがわかる。

「進む」ボタンを押す。

「インストール可能なオプション」が表示されるが、ウチのLBP-1310にはオプションを何もつけていないので、何もしないで「進む」ボタンをクリック。



「プリンタの説明」が表示されるので、それぞれの欄に適当に入力して、「適用」をクリックすると、登録が終わる。


これで、NAS経由でのプリンタの登録は終わり。
テスト印刷をしてみると、印刷できた。

NASもプリンタも、説明が少なすぎて、とてもわかりにくかった。
そもそも、プリンタの設定方法も、多すぎる。
コマンドラインとGUIがあり、webI/Fでの設定もある。プリントサーバはヘッドレスの場合もあるので、コマンドラインやwebI/Fを用意しなければならないし、一般的にはGUIが好まれるだろう。
設定方法が様々になってしまうのは、やむを得ないことだ。

CUPSのおかげでとても便利になったが、それでもまだまだわかりにくい。
これからも、うまく行ったらメモをとっておかないと。
印刷して残しておくかな。
2017/11/03 誤字修正と、引用文をスクロールするようにした。

2017/11/22 各章の小さい見出しを<h2>で書いていたが、<font><b>で書きなおした。
元々は記事の文字より少し大きい程度の明朝体のようなフォント(Timesが指定されていたが、実際の表示はブラウザによる)が使用されており、見出しとしてあまり目立っていなかった。ゴシック体のもう少し大きな文字にしたかったが、<h?>は記事以外のブログの部品でも使われており、勝手にstyleを書き換えるわけにはいかないので、<font><b>で書きなおした。

2017年10月28日土曜日

BLADE RUNNER 2049 を見てきた

Cyberpankの源流の1つとも言われる、Blade Runnerの新作を見てきた。
私にとってBlade Runnerは、大好きな映画の1つで、LaserDiskやDVDを持っている。
(LDはプレイヤーが壊れて再生できなくなってしまったが)

ガフやデッカードが出てきたり、さらには、レイチェルまでも...?
ところどころ前作の映像もはさみながら、懐かしい顔が見れたことは良かった。

人と機械の境界が曖昧になった世界。その世界観の描写も良かった。
なんとも言えない切ないシーンもあり、アンドロイドも人と同じように、苦悩するし夢も見る。

苦労した記憶の移植によって、レプリカントの精神を安定させる。前作でもレイチェルにはその処理が施されていた。
今回の作品でも、切ない経験によって、一台のレプリカントに変化が現れ、より人間に近くなる。

しかし、なんか消化不良。
なんとなく、中途半端な終わり方。
やはり、2つでは十分ではないのか?
2017年10月30日 追記
映画を見た時にもらったミニポスター(ただの絵葉書じゃん!)があったのを忘れてた。

机の上で撮影しようとしたけど、天井の明かりが写り込んで、うまく撮影できなかった。
しょうが無いので、壁に当てて撮影した。自分の指が写ってしまっている。

2017年10月22日日曜日

LibreOffice Draw でアニメーション作製#5

LibreOffice Draw でアニメーション作製
LibreOffice Draw でアニメーション作製#2
LibreOffice Draw でアニメーション作製#3
LibreOffice Draw でアニメーション作製#4

以前、LibreOffice Draw でアニメーション作製#2で、ダイアログで値を指定できるように、などと書いておいてほったらかしだった。
台風21号の接近で外は大雨なので、それをやることにした。
(ちなみに昨日は西伊豆の井田でダイビングをしていた)
まず、Drawでダイアログを作るには、[ツール(T)]→[マクロ(M)]→[ダイアログの管理(D)...]をクリックして、「LibreOffice Basicマクロの管理」ダイアログを開き、「新規作成」ボタンをクリックする。
「新しいダイアログ」ダイアログが表示されるので、適当に名前をつけて、[OK]ボタンを押す。
とりあえず、"PageSizeDialogDef"という名前にした。

そうすると、ダイアログエディタが現れる。
このへんのダイアログの説明を読んでから、適当に部品を配置して、適当に設定して...

こんな感じにする。
そしてハンドラを終了時に入力データを読みだしたり、幅の値の書き換えハンドラで高さの値を更新するようにしたりする。
なんという手抜きな説明だろう!
そんなんじゃ、全然わからないよ!!って、なるだろう。

というわけで、LibreOffice Basicのソースと、ダイアログのエクスポートファイルをダウンロードできるようにしておく。
Basicのソース: SavePagesAsBMP.bas
ダイアログのエクスポート: PageSizeDialogDef.xdl

実は、どうやればソースコード等を取り出せるのか、全然知らなかった。
作るだけなら、全く不要な操作だからだ。
しかし、1台のPCだけなら取り出し方なんか要らないが、デスクトップPCとノートPCを使っていると、もう一方のPCでも同じ機能を使いたくなるし、Backupする必要もある。
というわけで、Uploadした。
まだまだ手抜きだけど。

2017年10月20日金曜日

LibreOffice Draw でアニメーション作製 #4

LibreOffice Draw でアニメーション作製
LibreOffice Draw でアニメーション作製#2
LibreOffice Draw でアニメーション作製#3
LibreOffice Draw でアニメーション作製#4
LibreOffice Draw でアニメーション作製#5
今日も雨だ。
またもや、How to fold IKEA poncho. IKEAレインポンチョのたたみ方。で作ったアニメーションのコマを増やしてみた。

前回、コマ数を増やしてもわかりやすさはあまり変わらない。ストップモーションのほうがわかりやすいと書いた。
よく考えてみたら、アニメーションは動くばかりではなく、止めることもできる。
途中にタメを作るようにすれば、ストップモーションのようにすることができ、わかりやすさを損なわない。

途中のコマを書き足したり、途中にタメを入れたりして、アニメーション直した。
遊びで、最後の折り目が勢いよく反転する感じも入れてみた。
コミカルな動きになった。

今になれば簡単なことだが、滞りなくなめらかに動かすことばかり考えていて、止めることを考えてなかった。
何事も経験だな。

2017年10月7日土曜日

LibreOffice Draw でアニメーション作製 #3

LibreOffice Draw でアニメーション作製
LibreOffice Draw でアニメーション作製#2
LibreOffice Draw でアニメーション作製#3
LibreOffice Draw でアニメーション作製#4
LibreOffice Draw でアニメーション作製#5

ソースコードを見ていたら、直接GIFアニメーションをエクスポートするコードもあるようだ。
でも呼び出し方がわからないし、Drawではないのかもしれない。
無駄骨だったかもしれないが、いつものことだ。いろいろ勉強になったし、目的は達成できたのだから、良かった事にしよう。

それはさておき、せっかくLibreOfficeのマクロを書いたし、今日は雨で外に出れないので、 How to fold IKEA poncho. IKEAレインポンチョのたたみ方。で作ったアニメーションのコマを増やしてみた。
(雨ならば、ポンチョを着て外出しろって?)

以下がその結果。


コマ数はおよそ2倍になっている。
コマ数を増やしても、あまりわかりやすさは変わらない感じがする。
むしろストップモーション的な方が、1コマずつしっかりと見ることができて、解りやすい。

動画は動画でわかりやすいが、隠れて見えない部分もあるし、理解の前にどんどん進んでしまうという欠点もある。
絵は、見えない部分を表現することもできるが、動きがわかりにくい。
アニメーションは、その中間だ。

中間的な存在が、良いとこ取りになればいいが、悪いとこ取りになってしまうこともある。
コマ数を増やしたのは、悪いとこ取りになってしまったかもしれない。

最初の選択が、意外に良かったようだ。「この形だけは表現しないといけない」と思う絵を描いて、その途中を無理なくつなぐような必要最低限の絵だけを挿入していた。
過剰な情報は、混乱の元になる。技術的にコマ数が増やせるとしても、良いことかどうかは別だ。
技術に踊らされてはいけない。

2017年10月6日金曜日

LibreOffice Draw でアニメーション作製 #2

先週のLibreOffice Draw でアニメーション作製のつづき。
手動で.bmpにExportする場合、解像度を指定できる。
しかし、先週作ったマクロでは解像度を指定できず、デフォルト値の37ピクセル/cm(と表示されているが、正確には96dpi)で出力されることになる。
これを変更したい。しかし、ネット上で探すと情報がまとまっておらず、錯綜しており、混乱の極みだった。

まず、storeToURL()メソッドに渡すcom.sun.star.beans.PropertyValue型の.Name = "FilterData"でフィルタ固有の設定の入った配列を渡す。この配列もまたcom.sun.star.beans.PropertyValueで、いわば入れ子構造になっている。

ここまでは、先週の段階で解っていたところだ。
"FilterData"について、真剣に調べるとはまりそうな気がしたので、先週の段階では無視した。また、最初の1歩目は、あまり凝らずにさっさと閉じて、まず形にするのが私のやり方だ。

というわけで、今週の通勤時に、スマホで検索して調べた。
やっと見つけた記事が、OpenOffice-Basic GraphicExportFilter documentation?
まさにこれだと思ったが、コードの断片であり、説明はやはり無い。
下の方のリンクの文書を読んでみたが、"FilterData"の説明は書かれていない。
数日間、通勤時間の朝夕ほとんどをつぎ込んでも、結局"FilterData"について、まとめられた文書はどこにも見当たらなかった(自分の検索の方法が悪いのかもしれないが...)。

しょうが無いので、ソースコードを読んでみることにした。
https://github.com/LibreOfficeで、スマホでもソースコードを参照できる。
現在利用しているLibreOfficeのバージョンは5.1なので、そのGraphicFilterのソースコードを見てみる。
"FilterData"設定で見ているのは、PixelWidthとPixelHeightだけだ。
派生クラスなどでは他の値も使っているかもしれないが、基本的にはこれだけのようだ。
これらの値が、aRenderer.renderToGraphic()に渡されることになる。

サイズの指定がこれだけだとすれば、ドキュメントの縦横幅をピクセル数で指定しているだけと想像できる。
すなわち、dpiやpixel/cmのような物理量と関係する値ではない。そのページを縦横何ピクセルで画像にするかというだけだ。

試しに、先週のコードを以下のように改造して、実行してみた。
sub SavePagesAsBMP
    dim doc  as Object
    dim controller as Object
    dim pages  as Object
    dim prevCurrentPage as Object
    dim args(2) as new com.sun.star.beans.PropertyValue
    dim filterData (2) As New com.sun.star.beans.PropertyValue

    dim dirDialog as Object
    dim ucb as Object
    dim directory as String

    GlobalScope.BasicLibraries.LoadLibrary("Tools")
    doc = ThisComponent

    'MsgBox doc.DBG_properties
    'MsgBox doc.DBG_Methods
    'MsgBox doc.drawPages.DBG_properties
    'MsgBox doc.drawPages.DBG_Methods

    '------------------------------------------------------------
    ' Select directory by Directory Selection dialog
    '------------------------------------------------------------
    dirDialog = CreateUnoService( "com.sun.star.ui.dialogs.FolderPicker" )
    ucb = createUnoService("com.sun.star.ucb.SimpleFileAccess")

    directory = DirectoryNameoutofPath(doc.getURL(),"/")
    if ucb.Exists( directory ) then
        dirDialog.SetDisplayDirectory( directory )
    end if

    if dirDialog.Execute() <> 1 then
        exit sub
    end if

    directory = dirDialog.getDirectory
 
    '--------------------------------
    ' Save each page as .BMP
    '--------------------------------
    controller = doc.CurrentController
    pages = doc.drawPages

    args(0).Name = "FilterName"
    args(0).Value = "draw_bmp_Export"
    args(1).Name = "FilterData"
        filterData(0).Name =  "PixelWidth"
        filterData(0).Value = 900
        filterData(1).Name = "PixelHeight"
        filterData(1).Value = 800
    args(1).Value = filterData

    prevCurrentPage = controller.getCurrentPage ' preserve current page

    For i=0 to pages.Count -1
        controller.setCurrentPage( pages(i) )
        'url = directory + "/" + controller.getCurrentPage.Name +".bmp"
        url = directory + "/" + right( "0000000" + i, 8) +".bmp" 
        'MsgBox url
        doc.storeToURL( url, args )
    Next i

    controller.setCurrentPage( prevCurrentPage ) ' restore current page

end sub
ちゃんと、900x800で画像が保存できた。

一応動いたとはいえ、もう少しソースコードを追いかけてみたほうがよさそうだ。
また、独自のダイアログを作ることもできそうなので、次はそれを使って値を指定するようにしてみよう。

LibreOffice Draw でアニメーション作製
LibreOffice Draw でアニメーション作製#2
LibreOffice Draw でアニメーション作製#3
LibreOffice Draw でアニメーション作製#4
LibreOffice Draw でアニメーション作製#5
2017/10/20 リンクが間違っていた。張り直した。

2017年9月30日土曜日

秋の恵み

今年も秋の恵みの季節がやってきた。

いろいろ拾ってきたんだけど、現地で写真を撮ったのは、マテバシイだけだった。

すでに地面にたくさん落ちていた。
川沿いの入れない場所に落ちているので、残念だ。

その他、今日拾ってきたもの。
クルミはほとんどやられていて、写真のやつだけしか拾えなかった。
もっと早く来れたら良かったんだけど。

スダシイとマテバシイは、もっとたくさんある。

スダシイとマテバシイは、早速フライパンで炒った。
表面に色がつくと、いい匂いがしてくる。
生でも食べられるが、フライパンで炒ると、もっと美味しい。

椎の実はまだまだあるので、また拾いにいこう。