[IT] Line個人情報流出問題のあまりにもな今更感

 について。いや、なんなんでしょうね本当に。

 言わずと知れた日本国内シェアNo.1のSNSアプリLineについて、Line社の委託先であるところの中国企業から国内ユーザの氏名・電話番号を含む個人情報がアクセスし放題になっていた事が露見し、総務省はじめ政府各所で Lineの使用を取りやめる動きが続いているそうです。

何を今更、と思った人は少なくなかったでしょう。Lineが韓国企業製で、メインのサーバも韓国国内にある事はそれこそLineが普及する前から周知の事実であり、だからこそ大企業等では機密の漏洩が確実な事から利用が禁止されて来たわけで、昨今政府各所で行政サービスがLine連携を打ち出していたのも、その辺りの問題は承知の上だとばかり思っていたのですが・・・驚くべきことにそうではなかったようで。

紛うこと無き阿呆の所業という他ありません。名前からして時代錯誤感溢れるデジタル庁とやらの程度もお察しの通りという事でしょうか。先日中国への流出が報じられたマイナンバー関連も当然のように同様という事でしょう。そもそも、リテラシーのリの字も無い老人たちと建前と予算という名の既得権益の確保以外に何も考えていない官僚に、際限なく多様化する膨大な攻撃に対応し続けなければならない情報基盤の運営など、担える筈もなかったという事なのでしょう。至って当然の帰結であり、別に残念とも思いませんけれども、馬鹿馬鹿しいとは思います。

一般人は元々その辺は気にしない人が殆どだったでしょう（多分）から、中国韓国に個人情報やら一切合財筒抜けでも今更使うのを止めたりはしないのでしょう。そうしてアホがアホを晒し続けるのです。アホらしいですね。

[note] Ubuntu20.10にアップグレード

 しました。ファンキーでパワフルなGroovy Gorillaさんです。

と言っても、特筆する程の大きな変化はありません。例によってアップグレード後に幾つか不具合の類はありましたが、致命的と言えるようなものはありませんでしたし。（？）

それでも幾つか遭遇した問題点等につき、以下にメモ。なお、アップグレード元のバージョンは全て20.04LTSです。

[アップグレード適用時] ※update-managerから実行

 libc6のアップグレードの際、xscreensaverが邪魔とのメッセージが出て止まります。ので、下記コマンドで止めます。

　$ xscreensaver-command -exit 

 これ以外は、特にいつもと違う点はなし。

 [アップグレード適用後]

1. 起動失敗

一部のPCで、適用後、再起動に失敗するケースがありました。ログを調べてみると、bootパーティションのマウントに失敗している模様。/etc/fstabを確認すると、見覚えのない/boot/efiのエントリが入っていました。これにマウントしようとしているところのUUIDのドライブが見つからないという事のようで。ドライブを探しても良かったのですが、そもそもefiを使用する必要はない筈、という事で、このエントリ自体をコメントアウト。すると起動するように。

2. 一部アプリの不具合

起動後は大抵のアプリは問題なく動作したのですが、libreofficeについて少し問題が確認されています。何かというと、libreofficeの履歴メニュー（最近開いたlibreofficeファイルが一覧表示されるランチャー的なウィンドウ）を開くと、ウィンドウの左上側1/4部分しか表示されず、かつこのウィンドウ上からファイルを開くと、各アプリの画面も同様に左上側1/4しか表示されず、入力も受け付けなくなってしまうのです。ウィンドウツールキット周りの処理のバグでしょうか。

この点については、履歴メニューを経由せず、writerやcalc等の個別のアプリを直接起動する場合は問題なくウィンドウの全エリアが表示されます。これで回避出来るので、致命的な不具合というわけではありませんが、余計な手間が増える事には違いありません。速やかに修正されて欲しいものです。

3. 一部アプリが特に無告知でリポジトリから消えている

これはごく一部の人にしか関係しない問題でしょうけれども、私の常用していたアプリがアップグレードしたら消えていました。何かというと、SIPクライアントのLinphoneです。IP電話アプリですね。これを常駐するようにしていたのですが、消えていました。すぐに気づき、業務でも使用していた都合上、使えないのは困るので慌てて再インストールしようとしてもそもそもパッケージが見つかりません。SIPクライアントは元々あまり選択肢がなく、代替アプリは準備出来ていなかったところに、まさかのサイレントディスコンかとかなり本気で青褪めました。

焦りながら、20.04LTSまではaptでインストール出来ていたのに何故今更、と色々情報を集めることしばし。結論から言えば解決しました。

具体的には、Linphoneの提供方法が公式からのAppImage形式での配布に統一されたから、という事のようで、これを公式からダウンロードして使えばよい、ということでした。

ちなみにAppImageというのは、 Windowsで言うところのexeファイルのようなものですね。ディストリビューションや、カーネル及びライブラリのバージョンに（原則として）依存せず、かつインストール作業を要せず、ただ実行するだけでアプリを使用出来るように設計されたファイル形式というわけです。

というわけで、ダウンロードしたAppImageファイルに実行属性を付与してパスを通し、起動するようにすればそれでOK。無事Linphoneが使えるようになったのでした。起動してみると、従来は如何にも古いGTKのウィジェット的なウィンドウ表示だったのが、今風のスタイリッシュなアプリ表示に代わっていて、確かにこういう今風のデザインにするにはGTKやらに依存するわけにはいかないのも無理はない、と納得した次第です。何はともあれ一安心。

 取り敢えずはそれ位でしょうか。これでも以前と比べれば概ね問題ない、と言えてしまう辺り、今更ながら一般への普及が絶望的な事を再認識しつつ、気にしたところでどうしようもないし自分が使えるならそれでよしとしよう、というわけで今回はこれでおしまい。

[PC] ネットワークプリンタ新調

先日、前触れもなく、事務用のレーザープリンタが部分的に故障しまして。具体的には紙送りの不具合で、印刷しようとすると、ほとんどの場合に紙詰まりエラーが出る、というものでした。なお、機種はCANONのLBP3500、モノクロでA3対応の、プリンタ機能のみのシンプルなモデルです。

例外的に、手差しトレイに1枚のみセットして印刷する場合だけは上手く印刷出来るのですが、それ以外、つまりカセットでも手差しトレイでも、複数枚の用紙がセットされた状態から印刷しようとすると、何故か2枚目を読み込み掛けた状態で紙詰まりになるのです。1枚目を排出する前に止まりますから、計2枚が本体内に取り残されて無駄になることに。。。

これはおそらく紙送り部分の用紙を検出するセンサの不具合で、1枚目が通過したにも関わらず、センサ（のレバー）が戻らず、送り終えていないと誤認して紙送りを続けようとして、2枚目を引き込んだ後のタイミングで長時間紙送りが進んでいないと判断してスタックする、という事なのかな、と思われるのです。が、これを直そうにも、そのセンサ（と思われる）部分に物理的にアクセスするのが大変で、逆に分解する際に壊しかねない気がしまして。

そもそもLBP3500はもうかなり古いこともあり、取り敢えず、本機は封筒だとか厚紙だとかA3だとかの比較的特殊な、従って使用頻度のさほど高くない用紙の場合の手差しからの1枚印刷専用にする事にして、A4以下の通常用紙の（複数枚）印刷用のプリンタを別途新調する事にした次第です。

新しく導入する機種は、色々検討した結果、奥行きのコンパクトさやコスト（リサイクルトナーはじめ部品類の流通量の多さ）、印字品質（濃さ等）の安定性等を評価して、同じくCANON製のLBP6240に決定。納品後、有線LAN接続で繋いでセットアップしました。

Windows機用のセットアップについては特筆するような点はありません。従来機種同様、付属のセットアッププログラムを使えば簡単にセットアップ出来ます。ちなみに、本機にはモニタはついておらず、IPアドレスやMACアドレス等を取得するには、windows側の設定ツールを使うか、ステータスを印刷するかの2択になります。ステータスを印刷する場合は、排紙ボタンを長押し（3秒以上）します。

Linux機用の設定については、概ね次の通りです。 なお、OSは20.04LTSです。

1. CANONのサイトから対応するドライバをダウンロードし、解凍

　※LBP6240の場合、linux-carps2lbp-drv-v500-jp-17.tar.gz (ver.5.00)

　　https://cweb.canon.jp/drv-upd/lasershot/linux/carps2linux.html

　　ubuntuの動作確認済みは19.04までとなっていますが、20.04LTSでも問題なし。

2. フォルダ内でインストールスクリプトを実行

　$ sudo ./install.sh

　※なお、CUPSが起動されていない場合は、 ここで起動しておく。

　　$ sudo service cups start

3. CUPSの登録

　WEBブラウザから行う場合は、localhost:631にアクセスし、

　[管理] -> [プリンターの追加] -> [発見されたネットワークプリンター]中から、

　Canon LBP6230/6240を選択して追加

　ドライバ（モデル）の選択時も、Canon LBP6230/6240(en)を選択

以上で印刷出来るようになります。ただ、色々とアプリから印刷してみたところ、大体のアプリでは問題ないのですが、一部アプリではデフォルトの設定だと文字化けする不具合がありました。Libreoffice（のwriter）がその代表例ですが、これについては、アプリ側の印刷設定を修正する必要があります。

具体的には、プリンターのプロパティ（[ファイル]-[プリンターの設定]-[プロパティ]等）の[デバイス]タブ中、[プリンター言語の種類]を、デフォルトの[自動選択:PDF]から[PostScript（レベルはドライバーから取得）]に変更します。これで文字化けが直ります。

文字化けが出た時には少し焦りましたが、この程度の設定変更で解決するのならまあ許容範囲と言えるでしょう。以前のCANONのLinux対応のおざなりっぷりは目を覆わんばかりで、10年位前に当時のモデルでやろうとした時の設定の困難ぶりは半端なかったですからね。。。ともあれ、書類の印刷環境が回復して一安心。というわけで今回はこれでおしまい。

[note] 終わりと始まり、空虚なる一致

ようやく、と言うべきでしょうか。長きに渡った第２次安倍政権が終わります。

その開始当初から、失政を繰り返し、権力の濫用も絶えず、その責任も一切認めないという、無責任そのものを体現してきた同政権の終わりは、その応報によるものではなく、第１次の際と同じく持病による執務能力の不全による、至極あっけないものでした。貯まりに貯まったそのツケは、後継の政権が払う事になります。

とりわけ内政においては、いわずと知れたアベノミクス、すなわち公的資金から個人の資産まで、あらゆる資金を金融市場に流し込み、株や商品の価格を釣り上げ続けるという、あまりにも深刻な副作用に満ちた政策をその副作用が顕在化してなお止める事が出来ず、泥沼に嵌まり込むが如く続け、もはや日銀をはじめあらゆる金融機関が身動きも取れない状態に陥ってしまいました。

加えて、2020年に入ってからのコロナウィルスの深刻な流行、それへの対処に伴う経済活動の大幅な抑制によって、少なくとも今年度のGDP並びに個人・法人の所得は壊滅的な縮減を余儀なくされており、それらへの対処のために相当部分が無駄に費やされたと言ってよいであろう公金の額も過去に類を見ない規模に及んでおり、今年度の財政は既に破綻した水準にあるものと言えます。

無論、大小様々な事業の破綻、個人の失業も急増しており、それらへの救済を求める要求は減るどころか高まり続けています。しかし、長年財政支出への手当の半分以上を新規国債の発行に頼ってきた国家財政に、それらに十全に応える余力など残っていよう筈もありません。

誰が継ぐにせよ、次期政権は、この状況への対処を迫られる事になるわけです。どう見ても火中の栗どころではなく、地獄の門へ自ら踏み込むようなものだろうわけですが、それでも誰かが継ぐのでしょう。それは権力欲によるものかもしれませんし、この下手をしなくても経済が崩壊しかねない状況を回避ないしは軟着陸させる志を持って臨む向きも、無いではないのかも知れません。

とはいえ、現実的に最もありそうなのは、ここ数年の政権が行ってきた事を続ける、すなわち状況の先送りをしようとする事でしょうか。実際のところ、それ以外の、積極的に解決するような術があるようには思えませんし、しばらくはあまり変わらない状況が続く可能性が高そうです。あるいは、抜本的な修正、すなわち量的緩和の終了に乗り出す可能性も無いわけではないのでしょうけれども。

いずれにせよ、ただ、思うのです。大した違いはないだろうと。次の政権を誰が担い、何をしようとも、多分に破滅が来るのが早くなるか遅くなるか、またその時の落差が多少大きいか小さいか、の違いでしかなく、結局のところ行き着く先はさほど変わらないのだろう、と。

それは、第２次安倍政権の初期、日銀の量的緩和が始まった頃に思った事と全く同じだったわけで。過ぎ去った年月と、その間に人々が抱いた期待と失望、費やされた資金と労力、それらが殆ど無駄だったのではないかと、諦めとともに、虚しさを感じずにはいられないのです。

[note] Ubuntu上のGIMPでコピーしようとするとクラッシュするバグ

に遭遇しました。その際の対処についてメモ。

具体的には、Gimp上で画像の切り出し、を行うために、領域選択からのコピー（CTRL-C等）操作を行うとGimpが落ちる、というものです。ひどい。アプリ自体がまともに使えなくなるレベルの致命的なバグですね。

Ubuntuのバージョンは20.04LTS、デスクトップはLubuntu。Gimpのバージョンは2.10.18-1です。

多分にクリップボードとのやり取りにバグがあって、サイズやらハンドラやらが不正になってお陀仏というパターン、かと推測しつつ調査したところ、実はこのバグ、結構昔から頻繁に発生しているものらしく、数年前から上がっているバグ報告がチラホラ見つかりました。私は初めてでしたが、運が良かったという事なのか。ちなみに、私と同様の環境であるところのLubuntu上の2.10.18-1でのクラッシュ報告も既にありました。

で、報告されている対処方法は、基本的にクリップボード側の設定をいじるというものでした。代表的なものとしては、Kubuntu上だと、"画像を無視する"旨のオプションがあるらしく、これを有効にすると解消される、とのこと。他にも、クリップボード関連のアプリを入れている場合はそれを削除したりすればよい、等。あまりに発生する状況が多すぎて、対処方法も状況に合わせて多数あって逆にどうすればいいのかよくわからない、という困った状況でした。

少なくともLubuntuではそんなオプションあったっけ、な状態だったので、もう少し情報を探ることしばし。Lubuntuだとqlipperを削除したらいけたよ、という報告があったので、これを試してみました。下記コマンド。

$ sudo apt remove qlipper

しかる後に再起動すると、果たして領域選択からのコピーをしてもgimpは落ちなくなりました。

とりあえず一安心。しかし本件、Gimp側というよりはOS側のクリップボード周りの仕様（バッファのサイズ上限等？）がころころ変わるのが原因っぽいのですが、そんな基本的なところで致命的なバグにつながる変更をされるのはとても困りますね。検証不足、という見方も出来なくはないんでしょうが、基本的な部分はそもそも網羅的な検証なんてほぼ不可能です。というか、従来の仕様との齟齬が少しでもあればこういうバグが発生する事は避けられないわけで、であるからには基本いじらないのが鉄則だと思うんですが。。。ともあれ、今回はこれでおしまい。やれやれです。

[note] ubuntu20.04LTS、へのUPGで失敗して上書き再インストール

する羽目になっていた時の作業メモ。

いや参りました。Snapへの移行はじめ、幾つか割と大きな変更があるという話だったのでここ数回と比較して危険度は高めかもしれない、と思ってはいたのですが、悪い予感程当たるというもので。

いつも通り、リリースから数週間待って、update managerからアップグレードを試みたのですが、あえなく失敗。原因は不明。コマンドラインのdo-release-upgradeに切り替えたのですが、こちらも同様に失敗。

しかも悪い事に、パッケージの取得からインストールまで進んだ上で、その途中で失敗したものだから、システムの設定的には20.04LTSにアップグレードされた事になっていて、しかし各々のパッケージは中途半端に一部がインストールor置換されていない状態になってしまったのです。ここ数年特に問題が起きていなかった事に油断して、重要なデータ以外のシステムのフルバックアップを取っていなかったのもいけませんでした。

失敗したと言っても、カーネルや主要なライブラリ、またアプリは確認した限り新バージョンに置き換わっており、動作自体はするし、別にクラッシュしたりはしない・・・のですが、ログイン画面の背景のスケーリングがおかしかったり、ウィンドウの陰影等の装飾設定が変更出来なかったり、色々とちぐはぐというか、細かい調整がされていない感じです。それでいて、何が欠けていて、何が余計なのか、その調査判別は極めて困難という。

大部分はそれでも使用に難があるという程でもなかったのですが、受け入れ難い点もありました。最も致命的だったのは、日本語入力の不具合です。具体的には、fcitxとibusのいずれを使った場合にも、firefox等のmozilla製アプリやlxterminal等の一部ターミナルでIMEが起動せず、日本語入力が出来ないのです。

ウィンドウマネージャと各種IMの環境変数等設定を色々と変更して試してみた結果（抜粋）は概ね以下の通り。

1. 入力可
　chromium-browser, qterminal, emacs-gui等

2. WMや設定の組み合わせによっては不可な場合あり
　libreoffice

3. どの設定でも入力不可
　firefox, thunderbird, lxterminal(xterm)

この結果を見るに、ベースにしたツールキットの違いが原因と疑われる感じでしょうか。mozillaはマルチプラットフォームのために独自のツールキット（gtk+ベース？）を使っている筈ですし、おそらくは現環境（LXQt）のIM周り含むメッセージ処理についてブリッジのようなモジュールが必要で、それがアップグレードの失敗によって入っていない、とかそんなところかと。確認は困難ですが。。。qterminalはokでlxterminalがxなあたり、LXQtとgtk+の差な疑いが濃厚です。

他にも、LXQtでの標準ランチャー（lxqt-runner）を使ってみたところ、テキストボックスがポップする際、それにフォーカスが移らなかったり。都度ウィンドウを選択しなければならないのは如何にも手間でした。修正云々以前に、何故そんな事が起こるのか、謎です。

結局のところ、アップグレードの失敗によるだろう不整合点が多すぎて、手動でちまちま調べて修正するのはあまりに手間がかかる事は確実と思われる状態なわけで、流石にその路線は諦めざるを得ませんでした。同じような状況に陥った人は殆どいないようで、前例もほぼありませんでしたしね。

というわけで、初の上書き修復インストールで直す方針に切り替えました。まずドライブのパックアップを取り、インストール作業開始。

なお、最初はlubuntu（20.04LTS）のisoイメージを使ったんですが、これは途中（update-initramfs）でライブラリが足りない旨のエラーが出て、その修正も上手く行かなかったので、結局標準のUbuntu（20.04LTS）のisoイメージを使用しています。

基本は通常のインストール手順と同じ。上書きインストールの場合に異なる点は只一つ、インストール先のパーティションの設定の際、自動で設定や初期化等を行わず、手動（その他）での設定を選択し、かつ目的のパーティション（従来のルート）について、マウントポイントを'/'（ルート）に設定する事、です。また、マウントポイント設定の際、内容を保持する旨にチェックが入っている事を確認します。ここで内容を初期化する方（フォーマット等）にチェックが入っていたりすると全てが消え去り、バックアップの復元からやり直しになるので重ねて要注意。

後は通常のインストールと同じで、原則自動でインストールが進みます。 ただ、私の場合は、一点だけエラーが発生しました。具体的にはインストールのほぼ最終段、[以前インストールされたパッケージを復元しています...]の段で、復元に失敗したのです。その際のエラーメッセージは下記の通り。

＜エラーメッセージ＞
　インストールされていたアプリケーションの復元処理でエラーが発生しました。インストール は続行されますが、インストールが完了して再起動した後で、あらためてアプリケーションを 手動で再インストールする必要があります。

少し肝を冷やしましたが、致命的なものではなかったらしく、インストール自体は続行し、終了しました。後から確認した限りでは、確かにアプリケーションやライブラリが欠けていましたが、クリーンインストールの際と同様に追加すれば不足を感じる事はありませんでしたので、おそらくはもう使用していない類のサードパーティのリポジトリに関連するものが引っかかっただけだろうと思われます。

日本語入力等も可能に。firefox等でも日本語入力が出来ます。一安心。ランチャー（lxqt-runner）も呼び出し時にテキストボックスにフォーカスが移ります。

ただ、デフォルトの状態では気になった点は幾つかあります。qterminalのフォントが全角だったり、fcitxを入れる前にlubuntu-desktopを追加したところ、標準のibusだと何か問題があるのか、一旦日本語入力が出来なくなって、言語サポートも初期状態になっていたり。フォントは設定を変更すれば元通りになりましたし、日本語入力も新規インストールの場合と同様、常用しているfcitx-mozcを入れて設定すれば元通りになりましたが、若干不安を覚える点も無きにしもあらず、といったところでした。

また、ある意味当然ですが、/home以外のフォルダは全て初期化されます。/usr以下や/var以下を独自にカスタマイズして、そこに色々置いている人は多いでしょうけれども、それも一旦消えるので、それらを別途バックアップから復元しなくてはなりません。

やはり、アップグレードが正常に行われるに越したことはない、という事です。正直上書きインストールは二度としたくありませんね。ともあれ、何とか修正出来ただけよし、とすべきでしょうか。やれやれです。

[note] linuxにてデフォルトの再生デバイスの変更

をしたので、久しぶりにメモ。

事の始まり、という程大層な話でもありませんが、作業用のPC（ubuntu）について、USB接続のヘッドセットを繋いで使う事が増えまして。その一方、ヘッドセット（のヘッドホン部分）は一般にあまり音質は良くないもので、音楽等の音質を気にするような場合には向いていないため、そのような場合には従来の通りマザーボードの方の音声出力に別のヘッドホンを繋いで使用していたのですね。

そうすると、当然ながら再生デバイスが複数併存する事になって、用途に応じた切り替えが都度必要になるわけです。しかるにubuntuだと、pulseaudioのコントロールパネルから選択する方法がデフォルトで用意されています。時々使う程度なら、その都度パネルを開いて選択、という方法でも良かったのですが、ここで問題が生じました。WEBブラウザで動画を再生する場合等には、一時停止も含め、音声出力が途切れる際にその設定がリセットされ、デフォルトに戻ってしまうのです。デフォルトでない方を使っていると、再開やシーク、別動画の再生等、頻繁に行う操作の度にパネルから選択しなおさないといけないわけですね。

流石にこれは面倒だ、というわけで、デフォルトのデバイスを切り替える事にしました。しかしpulseaudioのパネルにはそれを行う項目がありません。色々調べてみても、結局のところ設定ファイルを書き換える（もしくはコマンドを実行する）しかないようです。というわけで、その方法を以下にメモ。なお、OSはubuntu20.04LTSです。

まず、デバイスのIDを取得します。下記コマンド。

$ pacmd list-sinks |grep -e 'name:' -e 'index:'

すると例えば下記のようなデバイスのリストが表示されます。

   * index: 1
        name: <alsa_output .usb-c-media_electronics_inc._usb_pnp_sound_device-00.analog-stereo>
    index: 2
        name: <alsa_output .pci-0000_08_00.1.hdmi-stereo>
    index: 3
        name: <alsa_output .pci-0000_08_00.6.analog-stereo>

これは私のPCの場合の出力ですが、今回デフォルトに選択したいのはindex: 3のデバイスです。ちなみにindex: 1はヘッドセット、index: 2はモニタの音声出力ですね。合計3種ある、という事です。変更前はindex: 1のヘッドセットがデフォルトになっていました。初期状態だと、番号順の先頭がデフォルトに設定される、という事でしょうか？

ともあれ。デフォルトのデバイスを切り替えるコマンドは下記の通り。

$ set-default-sink 'alsa_output.pci-0000_08_00.6.analog-stereo'

・・・なのですが、これをターミナルから実行しても、既に開いているアプリには反映されません。（反映されるタイミングについては未調査につき省略）

仕方がないので、今の所私は、設定ファイルに書き込み、一旦ログオフして再ログインする手順を踏んでいます。面倒ですが、そんなに頻繁にデフォルトを切り替える必要があるわけでもないので、とりあえずはいいか、という事で。設定ファイルは下記。

<設定ファイル>
　/etc/pulse/default.pa

このファイルのどこか（最下部にそれ用らしいエリアがあるのでそこでよい）に、上記コマンドを書き込みます。

しかる後に、一旦ログオフして再ログイン。これでデフォルトのデバイスが切り替わり、煩わしい選択作業から開放された、というわけです。やれやれ。

[law] マスク転売禁止に公然と違反する人たち

が沢山いると聞いて、少しばかり愕然とした次第です。

周知の通り、コロナウイルスの蔓延に伴うマスクの品不足に付け込んで、マスクを買い占めて法外な高額で転売する行為が横行していたところ、これが3/15に刑法上の処罰対象となりました。具体的には、国民生活安定緊急措置法第26条第１項に基づき、譲渡制限措置の対象に衛生マスクが指定され、卸売取引経由を除く一般向けの売買のほぼ全てについて、購入価格を超える価格での販売が禁止されたわけです。

罰則は一年以下の懲役もしくは100万円以下の罰金です。これはDV防止法の保護命令違反と同等であり、この種の規制におけるものとしてはかなり重いものとなっています。世間一般的に犯罪者の烙印を押されるレベルは超えている、と言えるでしょう。

なのですが、規制を掻い潜ってのオークション等での出品が続いている旨の報道が相次いでいます。それ自体は予想された事です。転売で高額の利益を得ていた者がその利益を維持しようとするのはごく自然な成り行きでしょう。

問題は、その手段です。ざっと見たところ、今の所用いられている手法は、以下の3つに大別されるようです。

1.卸等からの仕入れを装う
2.他の物品のおまけとしてマスクは無償と称する
3.名目上他の物品を取引し、実際にはマスクを販売する

これらの手法が、報道では抜け道等と表現されているようです。が、これのどこが抜け道なのでしょうか。

規制に対する抜け道、といえば、通常、法的には違法とは言えない手法を指すものです。脱法的、あるいはグレー等と言われるところの、法の趣旨からすれば本来規制されるべきものであり、その点からの非難は免れないけれども、明確に違法とは言えないために、現行法の適用で罰する事が困難な手法、と定義できるでしょうか。

しかし、上記の方法は、いずれもそのようなグレーなものではなく、単なる転売を、そうではないふりをして行っているだけの、すなわち明らかな違法行為であり、紛うことなき犯罪です。ネットオークション等のシステム上の規制、すなわち品名にマスクを含むものの出品禁止措置は回避出来るでしょうけれども、それはあくまで各システムの仕様上の不備を利用して出品禁止を回避するだけであって、法の規制を潜脱し得るものではなく、抜け道とは到底言えないものでしょう。

個別に見ると、1.については、仕入先を偽っているわけですが、その特定はそれほど難しい事ではないでしょうし、2.については価格に対するおまけの占める部分が購入価格より高いと判断されればそれで終わりです。3.については単なる虚偽表示です。いずれも、司法の捜査の手が入れば、極めて容易に露見するだろう程度の子供だましレベルのごまかしでしかありません。

そんな事もわからないのか、理解した上で摘発されないと高を括っているのかはわかりませんが、軽くない刑事罰を伴う犯罪が公然と行われる、しかもそれが多数に上る今の状況は、正直言って異様だと、戦慄を覚えた次第なのです。

ただでさえ施行直後は一罰百戒の意味も込めて特に摘発が行われがちな時期なのですし、これは早い段階で摘発の手が入るでしょうね。恐れを知らないというか、何というか。。。いやはや。

[note] 別役実死去

不条理劇といえば誰もが思い浮かべるだろう、別役実氏が亡くなられたそうです。82歳。そんな年になってたんですね。近年は表舞台に出る事も殆どなくなっていたとは言え、残念な事です。

近現代の演劇人でその影響を受けていないものはいないだろう巨人サミュエルベケット、その影響を最も強く受けた世代にあって、とりわけストレートに向き合った方でした。時間には誰も逆らえない、とは承知していても、演劇自体に往年程の活況が見られない昨今、一時代を築いた方々がこの世を去っていく事には、演劇界自体が衰退していく様を見せつけられているようで、一層の喪失感を抱かずにはいられません。

[note] gccの内部仕様変更に伴う不具合に悩まされた話

今回はバグ、というかプログラムのミスの話です。それ自体は別段珍しくもないのですが、その原因がちょっと今まで遭遇したことのない類のものだったのと、それを引き起こしたミスが、かれこれ数十年プログラムを書いてきて、今更こんな・・・と驚いたという中々珍しい組み合わせだったので、戒め代わりに晒してみようかと思った次第です。

何かというと、画像関連の自作ツールで、十年以上前からちょくちょく修正や拡張を積み重ねて来て未だに現役のプログラムがあるんですが、そのLinux版について、速度の最適化をサボっていたところを改善しようと、久しぶりにリビルドしたところ、落ちるようになってしまったのです。

使用言語はCとC++の混在、主なライブラリはgtk3(glade含)とあとgnu関連色々、コンパイラは普通にgcc・・・ということで、特殊なものは使っていないのですが、この辺をそれなりに使っている人はよくご存知の通り、これらの環境は頻繁に仕様変更が入ります。gtkなんか数年で関数や構造ががんがん廃止されますから、その度に修正が必要になってとても面倒なのです。

で、まあ今回もその類の内部仕様の変更による不具合だろう、ということでデバッグを始めたのですが・・・何か妙なのです。どういう風に妙かというと、ステップ実行していると、とある関数で、その関数の実行が終わって最後まで到達すると、通常なら当然呼び出し先に戻る・・・筈なところ、そうならずに関数の途中に戻っていたのです。数十行巻き戻る感じですね。当然、色々と齟齬が出ますので、すぐにバイオレーションになって死亡、というわけです。

正直参りました。この手の挙動は、往々にしてオーバーランや初期化漏れ等のバグに起因する事が多く、その原因箇所が落ちている場所とは全く別の場所である事が殆どで、特定は困難極まるからです。とはいえ直さないわけにもいかず、仕方がないので、まずは絞り込み、ということで、その関数周辺の処理を大まかなブロックに分けて、ブロック別に有効/無効を色々と切り替えて実行を繰り返し、挙動に変化が見られるか観察しました。

結果は、ほとんど変化なし。巻き戻る場所が変わる位で、相変わらず落ちます。絞り込みも出来ない、というのは初めてで、非常に困惑させられたのですね。

埒が明かないので、最適化オプションを変えてみたらどうだろう、とMakefileをいじって試したところ、-O0、すなわち最適化なしだと落ちない事がわかりました。一歩前進です。ただ、完全に治るわけではなく、落ちないながらも無限ループは発生することもあります。こういう再現性が不安定なのは一番困るのですよね・・・ますます困惑は広がるばかり。

とはいえ、この事から、原因の一端が最適化にあるものと推測する事が出来ました。ので、オプションを-O1,-O2等に切り替えたりしつつ、ステップ実行を繰り返して、観察出来る変数の内容をトレースして絞り込みを試みました。が、ご存知の通り最適化が入ると変数（の大半）がデバッガからトレース出来なくなるんですよね。このため、なかなか上手くいきません。

ろくに進捗のないまま、試行錯誤を繰り返す事数時間、これは詰んだか・・・と思い始めた頃、ふと気づいたのです。何にかというと、問題の関数はint型の返り値を返すものなところ、その最後にreturn文がない事に、です。明らかにバグです。

私は基本、関数を書く時は、関数名とその型の次にまずreturn文を書くところから始めるのが常(voidの時は除く)なので、return文が無いというのは個人的には非常に珍しいミスです。あるいは何処かの修正時に誤って消してしまったのかもしれませんけれども、その辺りは不明です。

ともあれ、こんなミスが・・・と驚き、まさかreturn文の有無がそんな致命的な挙動に影響しないだろうし、今回の不具合とは関係ないだろうな、と思いつつも、せっかく気づいたんだし直しておくか、とreturn文を追加したのです。

すると、あにはからんや、件のループが発生しなくなっているではありませんか。どの最適化オプションを付けても問題なく、以前と同様に動作します。図らずも解決した事になります。

正直、嘘だろうと目を疑いました。しかし、色々テストをしてみても、完全に直っています。認めざるを得ませんでした。これが原因だったのです。

この修正で直った、ということは、逆に考えると、今回の不具合は、"現バージョンのgccでは、return文が無い場合、特に最適化をすると関数の終わりを関数内部のループの終わりと誤認する場合がある"、という事なのかと。

なんじゃそら、と思わずにはいられなかったわけです。

無論、返り値が返されない、という状況は正しいものではなく、というか紛うことなきバグで、その状況すなわちバグを作ったのは自分自身である以上、それに苦しめられるのも自業自得であることはわかっているのです。

ただ、常識的に考えれば、その不具合が影響するのは通常その返り値を参照する箇所であるのが普通だと思うし、今回のような不具合の事象からこの原因を連想ないし特定するのは極めて困難、というか不可能だと思うのですね。。。本件解決法は、本当に偶然ふと気づいただけですし、あの気付きがなければ、今でもありもしない、いかにもやらかしそうな類のバグを探して無駄に苦しんでいたのかと思うと、ぞっとします。

gccもgtkも、サイレント修正なんて日常茶飯事ですし、またこういう修正困難なバグに遭遇する可能性も否定できません。そうでなくとも容赦なく行われる改廃に、その際の種々のトラブルの予防を図る事も出来ず、その度に対応を迫られ続けるのだ、という悲しい事実を、改めて噛み締めさせられた一件でした。どうにかならないものなのでしょうか。少なくとも自分で作る部分のバグは0にするしかない？そうですね。。。とほほ。

[note] タブレットのバッテリー交換

ご無沙汰してます、どころではないですね。一年以上ぶりの更新です。

久しぶりのネタは、先日、使用中のタブレットのうちの一台について、バッテリーが膨張して液晶が浮き上がる状態になってまして、その交換をした際の記録、という事になります。

本件、少し前（数ヶ月？）から、液晶の枠付近の色が黄色っぽくなっていまして、以前にスマホでバッテリーが膨張した際の変化と同じような、楕円形のシミのような変色も出ていたので、そのうち駄目になるんだろうな・・・と思っていたのが案の定、というわけです。膨張の原因はおそらく発熱で、本タブレットは元々性能の割に発熱があり、しかもプラスチック製の筐体で熱の籠もりやすい機種であったところ、本機でプレイしていたソシャゲのイベントがありまして、連続で長時間プレイして負荷が加わり続けたのがトドメになったものと思われます。最終的には、液晶が浮き上がって、横からLEDのバックライトの光が漏れるようになってしまっていました。

機種は、ASUS製Z380M。Zenpadの8インチ型ですね。廉価帯のモデルということで性能は低く、買い替えても1万数千円程度ではあるのですが、購入してから1年半程度で、バッテリー以外には問題もなさそうでしたし、OSもAndroidの6.0と現役、まだまだ使えるだろう、という事で修理する事にした次第なのです。

何はともあれまずは部品、という事でEbay経由で交換用のバッテリーを調達。ASUSのような大手製品は部品も入手が容易なのでこういう時は助かります。上記以前壊れたスマホは交換用部品がなく諦めたのです・・・とそれはともかく、型番は調べた限りてはC11P1510との事で、その互換品を購入しました。中国の深センの業者からの発送で、送料込み約2000円。２週間ほどで届きました。簡単な工具付です。（下図）

 一方、交換対象の方は下図。見事に膨らんでいます。カバーを開ける時、 弾け飛びそうな感じでした。カバーの明け方は省略。ネジを外して、爪を持ち上げつつパキパキと開けるだけです。なお、本体基盤の上側と下側をつなぐフレキケーブルが2本、バッテリーをまたぐ形で繋がれていたのですが、カバーを開けた際に膨張したバッテリーに引っ張られて外れてしまいました。外れたままだと動作確認も出来ないので、暫定的にバッテリーの下側を這わせています。

 

バッテリーの端子を外します。上に持ち上げてパコっと。

取り外したバッテリーユニット。おそらくはアルミ製のトレーに貼り付けられています。

 

バッテリーをトレーから剥がします。この時、粘着テープはかなり強力なものが使われているため剥がすのに苦労しますが、雑に扱ってバッテリーを損傷して発火したりしてはいけませんので、慎重に、ヘラ等を少しずつ粘着テープ部にコジ入れるようにして剥がすとよいでしょう。ちなみに私は、交換用バッテリーに付属してきたプラスチック製のピックを使いました。なお粘着テープは左右に二本取り付けられています。

交換用バッテリーと並べてみると、元が同じとはとても思えませんね。

トレーに交換用バッテリーを貼り付けます。なお、調達したのはC11P1510なのですが、取り外したバッテリーの型番はC11P1505で若干異なっていました。電圧・容量、サイズは同じなのですが、端子の位置が若干ズレています。交換品は少し外側に端子があるため、トレーに乗せる際に基盤端子に近づくように寄せて貼らないと、端子が届かなくなるので注意。下図で言うと左上ですね。寄せれば届きます。

フレキケーブルを元の通りに繋いで完了。フレキケーブルは端子後側のツメを上げ下げして噛み込むタイプですが、このタイプの例に漏れず華奢なので丁寧に。

ここで一旦動作確認。問題なく起動します。

安心したところで、カバーを閉じて、ネジ類を締めます。

無事修理完了、というわけで、今回はこれでおしまい。やれやれです。

[note] 浅利慶太死去

あの浅利慶太が、ついに逝ってしまいました。85歳だそうです。

純粋な商業としての劇団の常設、それもあの規模のものを複数、という、唯一無二と言うべき偉業を成し遂げた現代日本演劇界の立役者は、もういないのです。その喪失感は、寂しいという言葉では言い尽くせません。

彼を失った四季は果たしてこれまでと変わらずその存在を確として保ち、さらに発展させて行く事が出来るのか否か、それは誰にもわかりません。しかし、安易な目先の損得に惑わされず、これからも一層その輝きを強くして、社会に潤いを与え続けてくれる事を願う次第です。さよならだけが人生ではない筈なのですから。

[note] 往生際の悪い犯罪者たちの醜態がメディアを占拠し続ける様にうんざり

日大アメフト部の傷害事件で騒がしいこの頃。誰が見ても組織的に犯罪が行われた事は明らかなのに、この期に及んで自らの非を認めず、責任転嫁や稚拙な詭弁を弄して白ばっくれようとする監督はじめ日大関係者の理解し難い振る舞いには目を覆う他ないわけです。

他にも時を同じくして、政府周りも引き続き、学校法人を巡る権力濫用や、自衛隊の派遣を巡る不都合な事実等についての数々の虚偽・隠蔽が明らかとなり、これまた誰の目にもその事実は疑いようもない程明白なのに、ひたすら知らなかった、担当者や部門の独断、と、政府側にしか利はなく、独断で行う動機も利益もないのに、自らの関与を否定して白ばっくれようとしているわけです。

どちらも構造的には似たような話であるのですが、それが新聞・テレビ・ニュースサイトまで、あらゆるメディアで入れ代わり立ち代わりトップを占めているのですね。それらの間に挟まる話題も、多数の大手メーカー等での品質偽装やリニア談合等、やはり組織的な虚偽とその隠蔽のち言い逃れを続けた挙句に刑事事件になってあえなく御用、的な話が頻繁に表れます。

話題に登る誰も彼もが、規模や位置づけの点で重要な組織と、その責任ある筈の立場にある人物ばかりです。それが、判を押したように言い逃れや詭弁、責任転嫁を繰り返して自らの関与と責任を認めようとしない姿を晒し続けているわけです。彼ら以外のほぼ全員が、疑惑どころか議論の余地もない程に確信を抱いているにも関わらずのその振る舞いは、出来の悪い喜劇のようです。あれですね、裸の王様的な。

本当、どいつもこいつも嘘つきで、往生際が悪いったらありません。それで、こう、見渡す限りの情報がそんな話で埋め尽くされているのを見ると、日本国内のあらゆる組織のトップ周りの人間は皆犯罪者で、嘘つきで、それが明るみに出て、もはや言い逃れのしようもない事は客観的に明らかになってもその事実を認めない、不誠実な輩ばかりであるかのような錯覚を覚えてしまうのです。

冷めた目で見れば、企業やら団体やら、はては家族や隣人等の小さなコミュニティですら、上位者がその権力を有している事をいいことに、それをたやすく濫用し、あるいは部下等、組織内の下位の者に犯罪を強要し、それが露見しても責任逃れを図ろうとする、といった事は残念ながらありふれた事でしかないのだし、そういう凡庸な、愚か者がそのまま大学や政府等の、極めて大きな組織の上位者に就いてしまっている、それだけの事なのでしょうし、別段驚くべき事ではないのかもしれません。

ただ、事がもはや言い逃れのしようもないところまで至っているにも関わらず、見苦しく強弁や言い逃れを図ろうとし、それを広く見せつけ続けられるのは何の拷問だと。流石にいい加減うんざりするので、速やかにやめて頂きたいと思うわけです。。。が、まあそんな潔さがあるのなら最初からこんな醜態は見せないのだろうし、警察なり検察なり市民なりに告発されて、あるいは司法の強制によって退場させられる位しか解決の道はないのかもしれませんけれどもね。であれば、出来る限り早くそうなって欲しいと願う位しか仕方がないのでしょうか。

[biz] HONDAのモンキー125、価格は約40万円

と聞いて驚きました。いくらマニア向けとは言っても高すぎでしょう。売る気あるのかと。

確かに、諸々の事情で廃版になったモンキー50にはコアなファンが多数いたし、後継モデルを待ち望む声も多数あった事は事実であって、そこに一定のブランド価値があり、その分のプレミアムは許容され得る、というのはわかります。が、これは何か違うんじゃないかと。

そもそもモンキーのアイデンティティはまず第一に超小型バイク、だった筈で、それが巨大化した時点で意味不明だったわけですけれども、加えて値段も高い、という。巨大化に併せて排気量を125ccに上げた点も、モンキーに普通の出力や速度なんて求めてた人はいないだろうし、余計にこれじゃない感が強まったように思います。

ぶっちゃけ、ありふれた普通の125ccバイクなんですよねこれ。見た目をモンキーっぽくしただけの。それでいてデザイン料という事なのか、125ccバイクの相場から見ても値段は明らかに高いです。pcxより10万近く高いし、カブ110比だとほとんど倍。。。

それでもファンは買うんでしょうか。というか、ファンしか買わないでしょう。おそらくHONDAとしても、新規のユーザ獲得は最初から考えてもおらず、コアなモンキーファン向けにぼったくる事で採算をとろう、という考えなのではないでしょうか。

そりゃ２輪ユーザ自体が大幅に減少を続けて台数が期待できない中、少しでも稼ごうと思えばプレミアム路線になるのはある程度自然ではあるのでしょう。ただ、それにしてはコンセプトが崩れすぎなように思います。見た目だけモンキーな普通の大きさの普通の125ccバイク、というのが、超小型バイクを愛するコアなファンに訴求し得るのか、疑問を抱かずにはいられません。

逆にコアなファンであればあるほど、主たるコンセプトが崩れた事に幻滅してもおかしくなさそうなものですが、どうなんでしょうね。しかもこの価格だし、普通に考えればコケる可能性の方が遥かに高そうですが、さて。

新型の原付二種レジャーモデル「モンキー125」を発売

[biz] Kindle storeで海賊版コミックが堂々と販売される

流石に驚きました。先日AmazonのKindle storeに登録された某人気コミックの最新刊、これが丸ごと漫画村で違法公開されていた海賊版だったというのです。

しかもその発覚した理由が、版権者からの指摘ではなく、各ページの隅などに"漫画村"のスタンプがあったから、という誰が見ても一瞬でそうとわかる代物だった、というのだからわけがわかりません。

言うまでもない事ですが、これは著作権法違反の明らかな犯罪であり、著名作品ともなればその摘発を受けた場合の賠償金額は莫大なものになるだろう点で迂闊に犯せる類の罪ではない筈だし、とりわけ漫画村はここ最近の海賊版規制を巡る議論の中心にあって急速にその悪名が広まっているところのソースなわけで、しかもそれを当然ながらある程度の身分登録が必須のAmazonでこれをやるというのは。。。犯人は何がしたかったのかと。自滅願望の類があったとかいうのでなければ理解しづらいところです。

当然ながら本件はあっという間に対処がなされ、既に本件データは購入・参照出来ないようになっています。同時に、Amazon経由で版権者や司法関係にも通報がなされ、あるいは捜査等も始まっているでしょう。これが犯人の望んだ事なのか。世間を騒がせ、各所に騒動を起こすことが目的の愉快犯か、あるいは自身の自滅を臨む破綻者であれば、その望みは概ね達せられたものと言って良いのでしょう。単なる興味本位や、可能性は低いだろうけれども犯罪として摘発される可能性を考慮していなかった場合は大いに後悔する事になるでしょうけれども。

あるいは、販売は最初から目的ではなく、ここ最近俄に活発になっている海賊版規制を建前にした違憲そのものと言うべき通信の秘密の侵害たる検閲を導入しようとする動き、その議論における中心的な対象である漫画村について、あえて漫画村がソースである事を明示し、それにより容易にこうして海賊版を入手する事が出来る、という事実を広く知らしめる事で、世論における検閲によるネット規制の正当化を後押ししたい、というような、ある種の活動家的な意図があったのかもしれません。そうだとすれば、版権者や当局等の規制賛成派のマッチポンプの可能性も無きにしも非ずな感じがしてげんなりするし、そもそも犯罪をその手段にする時点で共感のしようもないわけですけれども。

いずれにせよ、理解し難く、また一々相手にするのも無意味な事件である事は間違いありません。このような馬鹿馬鹿しい行為が繰り返される事のないよう、速やかに摘発されるよう願いたいところです。

「漫画村」のロゴ入り漫画、Amazon Kindleストアで無断販売される　集英社「至急対応する」