5/25/2021

[note] No, we can't welcome anyone from outside of Japan.

So, Just do not come to Japan, Sincerely.

Due to COVID-19 pandemic, Medical resources in Japan is running out rapidly. Consequently, many Japanese patients are suffering (or die) without accepting appropriate treatment. Medical workers are exhausting.

We can't  even protect ourselves. How can foreign visitors? No way. We can't protect visitors.

If you, visitors came, and fell ill, we can't treat them without abandoning Japanese patients. If we do so, treated visitors may be hated by many Japanese, especially relatives of patients who are deprived of treatment opportunities.

It must be tragedy unbearable to see.

Situation is worsening. Nightmarish Indian variant of COVID-19 started to spread in Japan. But we have no way to fight with them. Many Japanese stay home alone, reducing contact with each other as less as possible already. But it can't help.

Tokyo Olympics? Just Crazy. 

IOC, JOC, and Japanese governments insists safe and secure Olympics is possible. But no safe nor secure in Japan.  They are fucking liars trashing many people's life into hell. Please stop their follies or ignore their baseless shits. 

So, if you are planning to visit Japan,  just stop. Even if you are athletes or participants attending to Olympics, do not come. It will help many people in Japan, and yourselves.

We can't welcome anyone from outside of Japan, whoever.

5/19/2021

[pol] コロナワクチンを薬扱いする非科学的姿勢を反省

今更な話なんですけれども。前回の、ワクチン接種システムの話を書いてて思ったんです。科学的な考え方が抜けてるんじゃないか、これはまずいなと。自分自身についてですよ。

何故かって、今国内で原則全員に接種をしようとしている"ワクチン"って、本来薬物なら当然に経ていなければならない治験も殆ど行われていない、従ってどんな副作用があるのかほぼわかっていない、そもそも薬と呼んでいいのかもわからない代物なわけで。 

勿論、これまでの海外での使用報告を見れば、抗体反応が出る事はわかっている以上、副作用に目をつぶればワクチンとして使える事は明らかです。が、その副作用が薬として許容出来るものなのかがわかっていない、それは文字通り致命的な問題である筈です。

特に長期的な副作用の有無またその傾向、及び各種の合併症等の組み合わせ的な性質については、科学的に言って全く不明と言っていいような状況です。短期的なものについても、治験であれば比較群の設定等で当然に排除されるその他の因子がごっちゃになっていて、それが無秩序に積み重なったところで意味を成しません。死亡者に最も特徴的に報告されるところの血栓の発生についてすら相関は不明という有様です。相関を認めうるのは、唯一アナフィラキシーについて位でしょうか。それにしたって仮説にすぎないという。mRNA方式は従来のウィルスベクタ方式に比べれば直接の害は少ないだろう、という仮説は立ち得ますが、そもそもmRNA方式自体知見が少ないという時点で考慮に値しません。問題がより複雑になっているだけです。

つまるところ、そもそも薬と呼んでいいのかわからないものなわけです。少なくとも科学に携わった経験のある人間としては到底受け入れられるものではない。それを、ただ欧米諸国を中心に広く接種が進んでいて、日本国内でもそれをそのまま受け入れ、倣おうとしているから、というだけで、何ら科学的な根拠もないままに、殆ど盲目的にワクチンとして受け入れている、その科学的な思考のかけらもない自分の認識の蒙昧さ加減に愕然として危機感を覚えた、という次第なのです。

そうは言ってももう接種は始まってしまいましたから、現実に、否応なく、副作用は生じます。発熱や痛みを感じる等の短期に回復し得る程度で済めば御の字、ワクチンによって殺される人も継続的に出るのでしょう。例え死んだとしても、それがワクチンによるものだと証明されず、因果関係の推測すらあやふやなために、碌に対処もノウハウの蓄積もなされないままに。そして、被害は抑制されず、当然に際限なく増える被害者への補償等も、少なくとも当面はなされないでしょう。薬害エイズよろしく、対応が始まるのはおそらく手遅れになってから。色んな意味で、遺憾極まりない話です。

相次ぐだろう死者は、本来の副作用による死者よりも相当に多い数が報告される筈です。というのも、元々高齢者はただでさえ死期が近く、ワクチンと直接の関係があろうとなかろうと、ワクチン接種から間を置かず亡くなる人は絶えないでしょうし、現状の要因の区別がままならない状況では、おそらく全て接種後の、接種と関係が否定できない死亡者として扱われざるを得ないだろうからです。そして、それが10人、100人、1000人と積み重なった時、人々の心理に与える影響が無視できるほど小さいものになるとは思えません。

例えば、因果関係は不明だけれど、ワクチン接種後に死ぬ確率は宝くじ1等当選(1000万分の1程度)より遥かに高い、というような情報が出回るようになったとして、不安に思う人は多いでしょう。基礎疾患の有無が主要因と言っても、高齢者で基礎疾患が全く無い人の方が珍しいわけですし。そして、不安になって接種を控える人も出るだろう事も想像に難くありませんが、それを非難する事は出来ません。そもそも薬と言えるのかすら定かではない、本来なら到底承認されていない代物であり、不安に思うのも当然だからです。それで死んでも国は責任取りませんしね。

全く以て正気の沙汰ではない現状、自分自身も少なからずその狂気に飲まれていた事は遺憾な限り。深く反省し、よくよく注意しようと思った次第なのです。 

[pol] ワクチン接種システム運用開始後の惨状を見て

5/18/2021

[pol] ワクチン接種システム運用開始後の惨状を見て

笛吹けど踊らず、というか。会場は未完成、警備員も手配せず、何を踊るのかも不明なまま、とにかく集まって踊れ、踊らなければ殺す、と脅して集めて踊らせようとした結果、会場入口前でドミノ倒しが起きたような。

いや、コロナのワクチン接種、その一般向け予約開始直後のゴタゴタの件です。

やろうとしている事は至極単純。高齢者に2回のワクチン接種を受けさせるだけです。成分が不安定なワクチンの性質上、極低温での保管が必要で、解凍後は即使い切らなければならず、また接種後も副反応に備える必要もある等の制約はあるものの、その実行自体はさほど困難なものとは言えないでしょう。

しかし、現実には大混乱です。その理由は何か。然るべき準備を行わず、通常なら当然の手順を踏んでいないからです。それと言うのも、無茶な期限を最初に設定し、かつそれに間に合わせるために最初から時間的効率を突き詰めた接種の実施を要求している点に原因がある事は明らかでしょう。つまり五輪が悪い。はよ捨てろ。

個別の問題点は幾つも挙げられます。まずそもそもワクチンの供給が不安定かつ甚だ不十分である事。それでも接種を行うためには供給量に応じて対象者を選別し会場へ誘導しなければならないけれども、対象者の母数に比しての供給量の少なさから、その枠を巡って奪い合い等の混乱が生じるだろう事。さらに、行政側の対応リソースの貧弱さから、速度面の要求を満たすためにその割当システムはネット上の予約システムを中心にせざるを得ないけれども、特に高齢者はそもそもネットリテラシーが低く、アクセスすら困難な者が少なくなく、選別・割当の問題以前に対象者の誘導が不可能なケースが多数生じる事。。。

行政側にこのような問題に対処するノウハウなどあるわけもありません。これから適応していくだろうと期待する事も出来ません。決定権を持つ政府の側も、五輪の開催予定時期前に終わらせる事を要求し、徒に、理不尽とも言える圧力を行政機関にかけるだけです。

そして碌に準備もせず見切り発車的に迎えた予約システムの運用開始と共に噴出する不備、不備、不備、そして混乱とそれに対する行政の言い訳に責任転嫁。これだけ注目を浴び、センシティブな情報が詰まったシステムです。興味本位の悪戯から、システム内の情報を窃取しようとするものまで、不正アクセスの類も半端な量ではないだろう事は始まる前から明らかでした。が、重複申請等のチェックすらしないという辺り、それに十分に備えた様子はかけらも認められません。ただでさえ正確な理解・利用が困難な対象者に、入力ミスや重複の検知すら出来ないシステム。どうやって不正アクセスと本来の申請とを区別するというのでしょうか。これでは上手く行くと考える方がどうかしています。

ネット予約自体は、接種のプロセス全体からすれば入り口に過ぎないにも関わらずのこの体たらく。これでゴリ押し出来ると、おそらくは今もって考えているだろう政府首脳以下責任者連中は、全員クビにした方が世のためだと、心底から思います。

付け加えると、システムの運用の可否は別にしても、個人情報の流出なんかも懸念されるんですよね。今のシステムの円滑な運用最優先な姿勢を見る限り、セキュリティ面はザルになっている可能性が極めて高いだろうし、まあもう無理だろうなと、殆ど諦めを抱かざるを得ないのが残念というか何と言うか。

[pol] ご都合主義的コロナ政策の末路

4/29/2021

[pol] ご都合主義的コロナ政策の末路

2021年のGWは、東京・大阪・兵庫・京都に新型インフルエンザ等対策特別措置法に基づく緊急事態宣言が発令される状況下で迎える事になりました。

また、首都圏・近畿の近隣県では限定的な緊急事態宣言と言うべき、同法に基づく蔓延防止措置も発令されています。従って、政府・自治体の施策の面では昨年とほぼ同様なわけです。

が、それに対する各個人・企業・店舗等、各種活動の実態としては、全くの別物と言う他ない状況にあるように見えます。

前提として、緊急事態宣言等に伴う政府・自治体から発令された正式な命令・要請のうち、過料等の制裁による強制力があり、かつ国民や各種業者の生活・経済に大きな影響のあるだろう主な内容は、概ね次の通りです。

・大型の商業施設・ホテル等のホール・集会場等の休業

・飲食店を中心とした小規模店舗の営業時間短縮

・各種スポーツ等のイベント・テーマパーク・展示会等の無観客化

・飲食店における酒類提供の禁止

・カラオケ禁止

この他、路上飲酒の禁止や宣言発令区域の出入り自粛等、法的根拠のない、従って強制力もない都知事らの口頭での要求が様々に発せられています。

もちろん、個人向けにも不要不急の外出を控える等の要請等が発令されているわけですが、これにも基本制裁がない、すなわち強制力がありません。

当然ながら、上記の命令・要請等に従った場合、個人・企業を問わず、程度の差はあれ損害が生じます。とりわけ、休業や酒類の提供禁止といった事業活動上深刻な損害を生ずべきものについては、相応の補償がなければ、事業者は経営が立ち行かなくなります。個人の場合は、経済的というより、精神的な苦痛等の方が大きいかも知れませんが、だとしても要請等に従った場合の損害は決して無視できるものではないでしょう。

また、これらの要請はここ一年以上繰り返され、それでいて終わりも見えない慢性的な状態が続いています。人は慣れる生き物であり、事態の長期化に伴い、当初抱いていた恐怖は薄れ、それに伴う危機感も当然に失われます。損害や苦痛を我慢しても意味がない、薄いと感じるようになれば、真面目に従わなくなる、どころか、従わずに済む抜け道的な方法を探すようにすらなるものです。

しかるに、強制力すなわち従わなかった場合に過料等の制裁があっても、損害に見合うだけの補償がなければ、公然・平然と命令等を無視して事業を続けようとする向きが増えるのも当然の帰結と言えるでしょう。いわんや、強制力がなく、当然ながら補償もない、いわば単なるお願いに過ぎない要請等、従うと考える方が愚かというものです。

その上、上記のようにあらゆる活動を罰則まで持ち出して禁止ないし制限しているというのに、五輪だけは例外、というより、国民の生命や生活を五輪開催のために犠牲にしようとしているとしか解釈のしようのない姿勢を顕にする政府や都のご都合主義的な振る舞いについては、もう何をかいわんやと。そんな意図が見えているのに、わざわざ彼らの政治的・経済的な都合に合わせて自分の損害や苦痛を我慢し、生活を犠牲にしようとする人は稀でしょう。

そもそも、本来なら、五輪のような尋常でない規模のイベントの開催前2ヶ月強の時期に、人員の手配どころか運営の方針すら定かでないような状況というのは、コロナ云々以前に論外というべきものです。医療スタッフの強奪をしようとして即失敗し、全方位的に非難が浴びせられていたのを見ても当然としか言いようがありませんし、この状況が早期に改善される見込みもありません。むしろこれから辞退者や参加拒否も一層増えるでしょう。

ワクチンもほぼ無力と懸念される変異株の蔓延したインドの惨状を見ても、五輪なんてとっくに諦めて、少なくとも医療関係のリソースはコロナ対策に集中し、それでも乗り切れるかどうか怪しい状況だというのを理解して・・・いないんでしょうね。

効果の定かでないワクチン、その必要数の確保すら出来ず、接種の体制を整える事も出来ず、しかし五輪前に高齢者4000万人弱の接種が終わるから大丈夫、とこの期に及んで寝言をのたまい、国民の生活や生命を含むその他の殆ど全てを犠牲にして狂気的に五輪開催に向け突き進む政府。行き着く先は国内での蔓延拡大に加えて変異株の大量輸入、文字通りの破滅でしかない事は明らかですが、歯止めがかかる見込みは今の所ありません。残念なことです。

3/19/2021

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

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

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

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

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

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

10/29/2020

[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やらに依存するわけにはいかないのも無理はない、と納得した次第です。何はともあれ一安心。

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

10/28/2020

[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年位前に当時のモデルでやろうとした時の設定の困難ぶりは半端なかったですからね。。。ともあれ、書類の印刷環境が回復して一安心。というわけで今回はこれでおしまい。

8/28/2020

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

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

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

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

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

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

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

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

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

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

7/12/2020

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

6/23/2020

[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以下を独自にカスタマイズして、そこに色々置いている人は多いでしょうけれども、それも一旦消えるので、それらを別途バックアップから復元しなくてはなりません。

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

6/22/2020

[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

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

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

3/16/2020

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

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

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

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

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

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

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

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

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

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

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

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

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

3/11/2020

[note] 別役実死去

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

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

10/22/2019

[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にするしかない?そうですね。。。とほほ。

10/07/2019

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

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

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

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

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

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


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

 

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


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


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


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


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




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





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


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




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