トマトを大量消費するメニューはなにがよい?

相変わらずトマトだけは大量に実っています。ピークは過ぎたものの毎日ミニトマトは2パック分、大玉トマトは2個くらいのペースで収穫できています。

そして食べきれずに数日分が貯まることもしばしばあります。そのような大量のトマトを消費するおいしいメニューランキングをかきます。 

第三位:
トマトのあさづけ:
 キュウリと一緒にあさづけしています。


第二位:
トマトライス
 よくオムライスの中にはいっているチキンライスに近いのですが、さきにトマトをトマトピューレにしておいて、炊き込みます。

第一位:
スパゲッティミートソース
 出来合いのソースを使わない場合はホールトマト缶を使うことが多いともいます。その缶詰の代わりに追熟して十分に熟れたトマトを使います。トマトが少ないと水っぽいソースになりがちですが、多量のトマトを使って十分に煮詰めるとうまみの濃いソースに仕上がります。

これ以上におすすめのメニューがあればコメントください

アプリに関係なく(ラなんとかも、なんとかgoにも)使える位置偽装

ここまでに書いた内容を読み返せばどのような手法で位置偽装するのかITエンジニアには理解できるでしょう。実現のためにはいくつかの条件はあるが、比較的簡単に実現することができた。
 要するに「 会社引っ越し後、WIFIで位置情報を検索すると前の住所が表示されます。 」や「 GoogleChrome・マップの位置情報 」などで起きているWiFiの情報に基づく位置情報の誤認識を利用するということです。これは意図せずおきれば誤認識なのですが、誤認識を誘発し一定の制御のもとにおけば、それは位置偽装といえるでしょう。この位置偽装の特徴はモバイル機器に追加アプリをインストールする必要がないことと、アプリに関係なく利用できることです。追加検証と有効性については別の場所で行うことにします。

 ここで扱う位置情報は本来の目的ではない情報を別の個人情報として扱うべき情報を組み合わせて実現した便利な機能により得られた情報です。情報提供者にほぼ無断で別の目的で利用していると言ってしまってもよいかもしれません。それはさておき、上の方法での位置偽装はいわゆる偽装アプリをインストールするわけではないので、偽装を検出することは困難というか、ほぼガードすることはできないでしょう。なんとかgo++のように利用できなくなったり復活したりというイタチごっこは発生しません。 さらにアプリに関係なく利用できるのも特徴です。

USB Linux(Ununtu)を一度起動すると、Windows10の時刻が変わる。対処できたが、このWin10の挙動は?

事象;USB Linux(Ubuntu)を起動して使用した後、Windows10を起動すると時刻がずれている。9時間遅い時刻つまり、GMT? UTCの時刻に変わっている。

暫定対処;暫定対処というよりも、事象発生時に「設定」→「時刻と言語」で、一度”時刻を自動的に設定する”もしくは”タイムゾーンを自動的に設定する”のチェックを外してもう一度”オン”に戻すと、正しい時刻にもどる。

原因調査; 推測:USB Linuxが、時計のタイムゾーンを設定していない状態になっており、Linuxを起動するとその状態がハードウェアに記録される。Windows10は起動しただけではハードウェアの設定を更新しないので時刻表示が変わると推測した。
Ubuntuを起動しtimezoneを確認した
$ timedatectl
Local time: Wed 2019-08-28 00:40:19 UTC
Universal time: Wed 2019-08-28 00:40:19 UTC
RTC time: Wed 2019-08-28 00:40:19
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
上の結果から、推測は当たっていると判断した。

根本対処、対処;
 上の確認結果から USB Linuxがハードウェア設定を変更しないようにすれば問題を発生させないと推測する。設定ベースでは、timezoneにAsia/Tokyoを設定することで解決すると推測される。

$ timedatectl set-timezone Asia/Tokyo
$ timedatectl
Local time: Wed 2019-08-28 09:44:03 JST
Universal time: Wed 2019-08-28 00:44:03 UTC
RTC time: Wed 2019-08-28 00:44:03
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

対処結果、結論:
 上の対処の結果は、USB Linux上にも記録される。また、一度Ubuntuを起動した後、Windows10を起動すると右下の時計の日時は何も設定変更しなくても正しい時刻を示すようになった。これで、問題解決であるが、Windowsの妙な挙動を検出した。Windows起動時に表示されるきれいな写真「 Windows スポットライト」 の左下に表示される時刻が9時間前の時刻になっている。気になる挙動だが、次回Windowsを起動するときには日本時間で表示される。どんな仕組みで9時間ずれが覚えられるのか、そしてWindowsを一度起動したら解消するのか。 上のメッセージの「 RTC in local TZ: no 」というのが怪しい。これを変えてみる。
$ timedatectl set-local-rtc true で解決できた。

スマートスピーカーがあればいらなくなるもの

一気に普及が進みそうな気がしていたスマ―トスピーカーだが、あまり普及が進んでいない感じがする。利用方法や活用方法がまだまだ整備できていないことが原因かもしれないが、なんといっても使い方があまり知られていないことが原因ではないだろうか。

今回は、スマートスピーカー単体で既存製品の機能を代替できるものについて書きます。つまり、スマートスピーカーさえあれば必要でなくなる既存製品のことです。そしてそれぞれのメリット・デメリットと既存製品が生き残るために取りうる選択肢を考えてみます。

 まず、スマートスピーカーが代替可能な領域です。最近はディスプレイ (タッチパネル) 付きのものも出てきているのでそれも対象にします。スマートスピーカーのインターフェイスの出力は音のみです。ディスプレイ付きのものは映像出力も可能です。入力は、音、タッチパネル操作、そしてインターネット上の情報です。インターネット上の情報はあまりにも広く絞り切れないので、入力側は考慮しないことにします。それから出力先としてインターネットが可能と考えることもできます。これは、あとで考慮することにします。
 出力が、音か、音と映像のみの既存製品とは何があるでしょうか?それらが、スマートスピーカーによって置き換えられる可能性がある既存製品です。ざっと上げると、タイマー、時計、ラジオ、などです。

■タイマー、時計
 ・ スマートスピーカー のほうは複数同時にタイマーが設定できるとか、スケジュールに連携とか可能です。
 ・「タイマー」については特にメリットが思いつきません。電源がなくても使えるというくらいです。スマートスピーカーの「xx分タイマー」の使い方を体験すると、時間を指定したうえでスタートボタンを押すなど操作が煩雑と感じるでしょう。

■ラジオ
 ・電波状態を気にすることなく明瞭な音で聞くことができます。録音に相当するタイムフリー機能が提供されていないことと、他の都道府県の局は受信制限がかかっている点は何とかしたいところですが、ラジオでも他県の電波を良質な音で聞けることはあまりないことを考えると不便とまでは言えないでしょう。

■以下にざっと挙げて、色分けしました。
青:すでにスマートスピーカー単体で代替できているもの。
黒:すでにスマートスピーカーと外部機器が連携して機能提供しているもの
赤:形を変えて対応しているもの

●楽器
●ウォークマン
●テレビ
●オーディオ製品、音響機器
●温度計、湿度計

●鏡
●カレンダー
●写真立て、フォトフレーム

●ゲーム、将棋盤
●新聞

●血圧計、体温計
●図鑑、本、辞書、電話帳、地図
●スキャナ
●ストップウォッチ
●スピーカ

●双眼鏡、望遠鏡
●そろばん
●体脂肪計、体重計
●タイプライター
●カメラ
●アルバム
●手帳
●電卓
●電話機

●投影機
●トランシーバー、無線機
●ノート、紙

●メガホン
●ラジオ、ラジカセ

上でざっと洗い出してみましたが、つぎのように漏れているものを見つけました。とくにスマートスピーカーで置き換えできそうなものです。まだまだピックアップし漏れたものがたくさんありそうです。電気製品の中に多いと思います。
・インターホン
ちなみに、インターホン相当の機能は私がグーグルに機能強化提案し2週間後くらいに密かにリリースされていました。私は、そのまえに「google home→googleアシスタント→IFTTT→node.js→google home」の流れでインターホン機能を実装できていました。

まだ十分とは言えませんが、スマートスピーカー単体で代替可能そうな機能はほぼ実装されています。使いにくいところは改善依頼をだして強化していけば、スマートスピーカーだけでのシンプルライフを送れそうです。

本格的なスマートホームへの移行までの対応例、SwitchBotでテレビをリセット

今回、紹介するのは取り付け作業に電気工事士などの資格が不要な製品です。物理的にスイッチ操作を行います。接着テープで貼り付けて、小さなサーボ機構でスイッチ部分を上下するので、 電灯のスイッチをON,OFFくらいならできます。コンセントなどにある電源スイッチの操作は厳しいでしょう。 しかし、資格が必要な作業が不要なので誰でも手軽に利用できます。まだまだ国内メーカ製のスマートスイッチは機種が少ないので、現状はSwitchBotを活用するシーンは多いでしょう。今後スマーススイッチが一般化していくことを考えれば、SwitchBotは過渡期の製品といえるでしょう。

SwitchBotは1回の操作で押すだけの操作、ONとOFFの動作、つまりワイドハンドルのスイッチの動作と、波型スイッチ(トグル)のON/OFFの動作の2つの動作モードがあります。工夫次第で、いろんな使い方ができそうです。

 テレビがハングアップしてしまいリモコン操作を受け付けなくなる事象が頻繁に発生して、そのたびにリセット操作をしていたので、SwitchBotにリセットボタンを押させるようにしてみました。下の写真がその取り付け例です。

SwitchBotのスイッチ部分にグルーガンで5mmほどの突起を作成して、リセットボタンを押せるように位置調整して取り付けました。
これに加えて、IFTTT連携、Google home連携も行いました。これにより、「ねぇ グーグル テレビをリセットして」というと、リセットボタンを押してくれます。

 SwitchBot自体はBluetoothで通信するので、SwitchBot単体ではスマートホンとかタブレットがないとうごきません。そこで、下のSwitchBotハブと組み合わせて使用します。

次のような構成で動作します

SwitchBot
  ↓ Bluetoothで通信
SwitchBotハブ
↓ WiFiで通信
無線LAN ルータ
↓ 光ケーブルや有線LANなど
インターネット

SwitchBotのサーバ ←→ IFTTTのサーバなど

最近は、SwicthBotハブプラスなども提供されているのでIFTTTの他のサービスと組み合わせるなどの工夫でもっと色々使えます。


 それから、気が付かないうちに録画機能だけハングアップしていて予約録画できていなかったこともありました。そこで、まず視聴や予約録画していなさそうな午前4時に毎日自動的にリセットするようにIFTTTのルールを作成しました。これにより、ハングアップ状態でずっと録画できないままという事象も回避できました。

話は、SwitchBot自体に戻りますが、 SwitchBot は内蔵の電池で動作します。最初は蓋の隙間から横に飛び出している絶縁ビニールを抜いて電源をいれます。電源を切る仕組みはありません。もちろん電池を抜けばよいのでしょうが普通に使うならそんなことはしないので入れっぱなしです。1日に1回か2回くらいの操作をして、1年くらいで電池が切れました。ちなみにほとんど使っていなくても1年くらいで電池が切れました。

中に入っている電池はつぎのようにCR2 Lithium Battery CR15H270 3Vです。電池が切れたときはこれを交換します。近くのホームセンターで1個 448円で交換用の電池を購入しました。

使うときは、電気交換のことも考えながら使ったほうがよさそうです。接着テープは一度剥がすと接着力が落ちるので、手が届きにくいとか、一度SwitchBotの本体をとりだす必要があるなど、いちど接着テープを剥がさないと電池交換できないような場所には不向きです。
  ただ、そういう場所にこそ使いたいかもしれません。

太陽光発電の経年劣化による発電量の減少とメーカー保証について

前回の解析に続いて、経年劣化の状況を整理しておきます。最初に実際のデータです。7月の発電量のうち発電量が最大だった日のデータを年ごとにプロットしたものです。3つとも劣化していることが分かります。変更の影響を受けている部分はありますが、全体的な傾向から劣化していると言ってよいでしょう。

このような経年劣化に関連した保証しているメーカーもあります。まずはその辺から、保証内容にまとめたサイトもありますので全体像はそちらを参考にしてください。ここでは、経年劣化に関する保証内容のみをまとめます。

メーカ名10年保証11年以降
パナソニック JIS C 8918の7.1(性能)に示された公称最大出力に対して、10年で81%未満 25年で72%未満 ※1
シャープ JIS C 8990で規定するAM1.5、放射照度1,000W/m2モジュール温度25℃、最大出力の90%を基準にしてその90%11-15年 85%
16-20年 80%
京セラ公称最大出力の81%10-20年 72%
東芝 JIS C 8918の7.1(性能)に示された公称最大出力に対して、10年で81%未満 25年で72%未満
長州産業 CIC JIS C 8918 に示された公称最大出力に対して、81%未満 11年目から15年間 :72%未満※1
ソーラーフロンティア 公称最大出力の交差範囲内の最小許容値に対して10年で10%以上低下 20年で20%以上低下

※1:手続きをいろいろしておかないと保証書も発行されない仕組みになっている。みんなちゃんと手続きをしているのだろうか?

上の通り81%未満のメーカが多い。公称最大出力を基準としているところが多いが、実際の発電量と見比べたとき、何パーセントになったときに保証されるものなのか非常に分かりにくい。上の実際のデータで見てもわかるように10年で初期の発電量の80%程度になることは当たり前のように推測されます。

 そして、どうなったら「保証の対象」つまり保証の基準を下回っていると判断されるのかをメンテナンス会社に聞いてみましたが、判断基準や確認方法についての返事は帰ってきませんでした。 80%とか70%の微妙な数字では、「天候や太陽高度の影響により変わる」というごく当たり前のことをいって保証の対象外とされています。たぶん出力が初期の50%以下になるとか極端な数値にならないと保証されないでしょう。

2013年7月
発電量(1日分)
2019年7月比率
劣化度
site154.0kWh45.584%
site232.027.686%
site365.655.785%

上表のように発電量は10年で初年の80%程度の発電量となるので、発電収入などを見積もるときは平均的にこの程度の劣化があるものとして見積もったほうが良いでしょう。

Hyper-V上に Ubuntuで開発支援環境を整備する

方針:
 Windows10環境上にLinux(Ubuntu18.04)ベースで開発支援環境を整備する。開発環境のため長期間安定運用できる見込みの18.04を採用しています。

■1.Hyper-Vが使える状態にWindowsを構成しなおします。
PROとか上位エディションでないと使えません。
次を参考に設定する
Hyper-Vの使い方 Windows 10にWindows 7インストール
上の手順で特に補足はありません。

■2.Hyper-Vに UbuntuのVMを作成、インストールします。
Hyper-V で無線 LAN のみの PC でもネットワーク接続できるようにする方法
補足:上の手順の設定のままやるとメモリが不足する可能性が高い。起動メモリは自分のマシンのメモリサイズに合わせて決めてください。ホストOSにもメモリが必要なので半分程度を基準に、使い方に合わせて調整して割り当ててください。例えば全メモリサイズが8GBなら4GBを割り当てるといった具合に調整してください。

■おまけ:
ここで、VMから無線WiFiデバイスが使えるか確認してみました。
Hyper-V で無線 LAN のみの PC でもネットワーク接続できるようにする方法」などの情報があります。そりゃそうだ、というか、デバイスはホストOSが管理しているのでゲストOSには直接見えませんよね。つまり、無線WiFiで通信することはできるが、それはブリッジを介して接続するのでUbuntuからはブリッジ接続が有線接続のように見えるということです。よって、やりたいホットスポットとして使用することはできない。 Windows10で起動したホットスポットに対してブリッジ接続することでそれらしい動きはできそうです。しかし、これも Ubuntuからは有線接続として見えるのでUbuntuからはWiFiデバイス操作はできず目的を果たせません。

■3.terminalから ツールを追加インストールする
・まずネットワークの状態を確認するためにnet-toolsをインストールする
sudo apt install net-tools
  → ifconfigで IPアドレスなどを確認する
・ホストOSから軽るーくsshで操作したいので、sshをインストールする。
sudo apt install ssh
 → ここまでの設定で特に追加設定しなくてもホストOSから上で確認したIPに対してSSHで接続ができます。ここから下はsshからの操作でも作業できます。
・Ubuntuのメモリ消費量を削減するためにCUIで起動するように変更する
sudo systemctl set-default multi-user.target
 →VMを再起動すればCUIで起動する
・開発用のツールを導入する
sudo apt install build-essential
  →これだけで大丈夫そう。さきに下の4つのインストールを実施し後述の問題が発生したので、上インストールも実施、build-essentialのみの動作は未確認
sudo apt install git
sudo apt install make
sudo apt install make-guile
sudo apt install gcc
  →ここまでとりあえずは構築完了。 以下はビルド確認での問題。

■4.ビルドでの確認
つぎのページを参考にrtl8188eusのドライバをビルドしてみる。
https://ficus.myvnc.com/ja/blog/RTL8188%E3%81%AB%E3%82%88%E3%82%8BOrangePi%E3%81%AE%E3%83%AB%E3%83%BC%E3%82%BF%E5%8C%96Vol.2_b82

$ git clone –single-branch –branch v5.2.2.4 https://github.com/capitalfuse/rtl8188eus.git
$ cd rtl8188eus
$ make

次のようにビルドに失敗


hbox@hbox-Virtual-Machine:~$ git clone –single-branch –branch v5.2.2.4 https://github.com/capitalfuse/rtl8188eus.git
Cloning into ‘rtl8188eus’…
remote: Enumerating objects: 1173, done.
remote: Total 1173 (delta 0), reused 0 (delta 0), pack-reused 1173
Receiving objects: 100% (1173/1173), 3.71 MiB | 1.44 MiB/s, done.
Resolving deltas: 100% (693/693), done.
hbox@hbox-Virtual-Machine:~$ cd rtl8188eus
hbox@hbox-Virtual-Machine:~/rtl8188eus$ make
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.0.0-25-generic/build M=/home/hbox/rtl8188eus modules
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ に入ります
CC [M] /home/hbox/rtl8188eus/core/rtw_cmd.o
CC [M] /home/hbox/rtl8188eus/core/rtw_security.o
CC [M] /home/hbox/rtl8188eus/core/rtw_debug.o
CC [M] /home/hbox/rtl8188eus/core/rtw_io.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ioctl_query.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ioctl_set.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ieee80211.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mlme.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mlme_ext.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mi.o
CC [M] /home/hbox/rtl8188eus/core/rtw_wlan_util.o
CC [M] /home/hbox/rtl8188eus/core/rtw_vht.o
CC [M] /home/hbox/rtl8188eus/core/rtw_pwrctrl.o
CC [M] /home/hbox/rtl8188eus/core/rtw_rf.o
CC [M] /home/hbox/rtl8188eus/core/rtw_recv.o
CC [M] /home/hbox/rtl8188eus/core/rtw_sta_mgt.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ap.o
CC [M] /home/hbox/rtl8188eus/core/rtw_xmit.o
CC [M] /home/hbox/rtl8188eus/core/rtw_p2p.o
CC [M] /home/hbox/rtl8188eus/core/rtw_tdls.o
CC [M] /home/hbox/rtl8188eus/core/rtw_br_ext.o
CC [M] /home/hbox/rtl8188eus/core/rtw_iol.o
CC [M] /home/hbox/rtl8188eus/core/rtw_sreset.o
CC [M] /home/hbox/rtl8188eus/core/rtw_btcoex_wifionly.o
CC [M] /home/hbox/rtl8188eus/core/rtw_btcoex.o
CC [M] /home/hbox/rtl8188eus/core/rtw_beamforming.o
CC [M] /home/hbox/rtl8188eus/core/rtw_odm.o
CC [M] /home/hbox/rtl8188eus/core/efuse/rtw_efuse.o
CC [M] /home/hbox/rtl8188eus/os_dep/osdep_service.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/os_intfs.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/usb_intf.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/usb_ops_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/ioctl_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/xmit_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/mlme_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/recv_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o
/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.c: In function ‘rtw_get_systime_us’:
/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.c:354:2: error: implicit declaration of function ‘get_monotonic_boottime’; did you mean ‘getboottime’? [-Werror=implicit-function-declaration]
get_monotonic_boottime(&ts);
^~~~~~
getboottime
cc1: some warnings being treated as errors
scripts/Makefile.build:284: recipe for target ‘/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o’ failed
make[2]: *** [/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o] Error 1
Makefile:1606: recipe for target ‘module/home/hbox/rtl8188eus’ failed
make[1]: *** [module/home/hbox/rtl8188eus] Error 2
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ から出ます
Makefile:1911: recipe for target ‘modules’ failed
make: *** [modules] Error 2
hbox@hbox-Virtual-Machine:~/rtl8188eus$

同様に別のページを参考に他のドライバをビルドしてみたが別のエラーで失敗した。

$ make
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.0.0-25-generic/build M=/home/hbox/rtl8188fu modules
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ に入ります
CC [M] /home/hbox/rtl8188fu/core/rtw_cmd.o
In file included from /home/hbox/rtl8188fu/include/osdep_service.h:41:0,
from /home/hbox/rtl8188fu/include/drv_types.h:32,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
/home/hbox/rtl8188fu/include/osdep_service_linux.h: In function ‘_init_timer’:
/home/hbox/rtl8188fu/include/osdep_service_linux.h:273:8: error: ‘_timer {aka struct timer_list}’ has no member named ‘data’
ptimer->data = (unsigned long)cntx;
^~
/home/hbox/rtl8188fu/include/osdep_service_linux.h:274:2: error: implicit declaration of function ‘init_timer’; did you mean ‘_init_timer’? [-Werror=implicit-function-declaration]
init_timer(ptimer);
^~~~~~
_init_timer
In file included from /home/hbox/rtl8188fu/include/drv_types.h:35:0,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
/home/hbox/rtl8188fu/include/wifi.h: At top level:
/home/hbox/rtl8188fu/include/wifi.h:1009:0: warning: “IEEE80211_MAX_AMPDU_BUF” redefined
#define IEEE80211_MAX_AMPDU_BUF 0x40

In file included from /home/hbox/rtl8188fu/include/osdep_service_linux.h:84:0,
from /home/hbox/rtl8188fu/include/osdep_service.h:41,
from /home/hbox/rtl8188fu/include/drv_types.h:32,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
./include/linux/ieee80211.h:1444:0: note: this is the location of the previous definition
#define IEEE80211_MAX_AMPDU_BUF 0x100

cc1: some warnings being treated as errors
scripts/Makefile.build:284: recipe for target ‘/home/hbox/rtl8188fu/core/rtw_cmd.o’ failed
make[2]: *** [/home/hbox/rtl8188fu/core/rtw_cmd.o] Error 1
Makefile:1606: recipe for target ‘module/home/hbox/rtl8188fu’ failed
make[1]: *** [module/home/hbox/rtl8188fu] Error 2
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ から出ます
Makefile:1679: recipe for target ‘modules’ failed
make: *** [modules] Error 2



エラー内容をもとに調べてみると、
https://forum.manjaro.org/t/solved-error-with-rtl8812au/24066/2
https://github.com/smlinux/rtl8723de/issues/13
ドライバーのソースとカーネルバージョンの不一致が原因と言っている。
そこで、カーネルバージョンを確認する。→「カーネルバージョンの確認方法」

$ uname -a
Linux hbox-Virtual-Machine 5.0.0-25-generic #26~18.04.1-Ubuntu SMP Thu Aug 1 13:51:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

対象のカーネルバージョン用のドライバソースをビルドしてみます。
https://github.com/FreedomBen/rtl8188ce-linux-driver
→このソースは4.20にも対応しているとコメントがあるのでこれで試します



$ git clone https://github.com/FreedomBen/rtl8188ce-linux-driver.git
$ cd rtl88188xce-linux-driver/
$ make

ビルドに成功しました。 やはり、ドライバーソースが対象のカーネルバージョンに対応していなかったことが原因でした。

台風直撃、風も雨もそれほどひどくなかったが収穫直前のトウモロコシはほぼ全滅

あと10日くらいで収穫できそうだったトウモロコシでしたが、台風の風でほぼ全滅しました。さすがに2メートル越えの背丈だと耐えきれないのでしょう。

台風の目に入ったほど直近を通過した台風でしたがこの場所の雨量は30mmほどとほとんど降りませんでした。風もそれほどひどくはなかったのですが上の写真のようにトウモロコシはほとんど倒れてしまいました。近くの気象台のデータでは最大瞬間風速が11m/s台で、台風でなくても時々ありそうな数値です。ちょうどトウモロコシの背丈や実の付き具合で弱い状態になったところに風が吹いたので倒れてしまったと推測できます。残念ですが完全に倒れたものは諦めて収穫しました。まだ実はほとんど入っていませんでした。

 トウモロコシを取り除いた後には台風来襲に備えて植え付けを先送りしていたナスを植えることにします。

USBメモリにパーティションを作成する手順とツール (EaseUS Partition Master編)

先にUSBメモリにPCにインストールすることなく利用できるLinuxを構築しました。この際にUSBメモリ上にパーティションを作成して手順を紹介します。今回はパーティション管理ソフト「EaseUS Partition Master 13.5」を使用して作成する手順を紹介します。
下では「EaseUS Partition Master」を使用していますが「 EaseUS Partition Master Free」でも同様に使用できると思います。 またこのツールはデータリカバリやバックアップの機能もありディスク管理ソフトの色合いもある製品です。

目的;
 「インストールせずにUSBから起動するだけで動作するLinux環境を構築する」これを目的に、次の構成でパーティションを切ります。

パーティション1
 ファイルシステムFAT32
 パーティションサイズ 8GB(Linuxのインストール+Persistentのサイズ)
パーティション2
 パーティションラベル Persistence (この名称のパス名でマウントされる)
 ファイルシステム Ext3 (ツールがExt4未対応のためExt3としています)
 パーティションサイズ USBメモリの残り全部

●0)準備
 easeus.comのサイトからファイルをダウンロードしてインストールします。
下では「EaseUS Partition Master Pro 13.5」を使用しています。ダウンロードしたファイル名は「epm_trial_installer」でした。これ実行すると下のようにインストーラ本体をダウンロードしインストールします。

インストールが終わるとデスクトップにつぎのアイコンができます。これをクリックして起動します。

●1)「 EaseUS Partition Master 」が、つぎのように起動します。

●2)起動した画面でUSBメモリのディスク番号を確認し、下の操作対象の領域を確認します。

●3)操作した領域にパーティションがすでに確保されている場合は、パーティションを削除して、”未割り当て”状態にします。対象のパーティションを右クリックして”削除”を選択します。
→補足2参照

●4)つぎに「パーティション1」を作成します。対象の領域を右クリックして”作成”を選択します。

●5)「パーティション1」としてファイルシステムをFAT32、プライマリ、パーティションサイズを8GBに指定してパーティションを作成します。

●6)”作成”で「OK」をクリックすると、つぎの注意ダイアログがでます。「OK」をクリックして継続します。
→補足1参照

●7)つぎにパーティション2を作成します。
  パーティションラベルに”persistence”、ファイルシステムは”Ext3”、プライマリを指定し、パーティションサイズは残りすべてを割り当てます。

※この時点では、右側のパーティションは削除されように見えていますが、操作に登録されているだけで、まだ実際には削除などの操作はされていません。

●8)操作内容と構成イメージを確認し、問題なければ左上の”操作を実行する”をクリックします。

●9)つぎのダイアログが表示されるので、「適用」をクリックします。※ここで”適用”をクリックしてしまうと後戻りできません。間違いないことを確認してください。

●10)操作の適用中は下のダイアログで進行状況を表示します。
 USB 2.0の64GBのUSBメモリの構成で完了までに1時間47分かかりました。

●11)適用が完了するとつぎのように「完了しました」のメッセージが表示されます。

●12) 「EaseUS Partition Master 」を終了した後、USBメモリを取り外します。

以上で、USBメモリのパーティション構成が完了します。 いくつか補足がありますが「EaseUS Partition Master 」でGUIでの簡単な操作のみでパーティションの操作が行えます。
 下に主に 「 EaseUS Partition Master 」 の開発者向けのコメントを書きます。

■補足1
「Windowsはリムーバブルデバイス上の最初のプライマリパーティションのみ識別します。もしプライマリパーティションがない場合は最初の論理パーティションが識別されます。続行しますか?」
→正しいのかどうか判断が難しいほど情報量が多いです。
 1) もう少しわかりやすい説明をしたほうが良いですが、そのためには図を使うなど別のページに記載して、このダイアログではそのページをポイントするなどして参照してもらうようにしたほうが良いでしょう。
 2)Windows10では1つめ2つめともにパーティションを下のようにFAT32でフォーマットすると認識できました。 下の画像ではH:とX:の2つのドライブで認識しています。 このため、「 最初のプライマリパーティションのみ識別します。 」は不適切ではないでしょうか。旧バージョンのWindowsでは認識できないのなら、”WindowsXX以前では”のような表現を追加したほうが良いです。

■補足2
「パーティションサイズ調整/移動」や「削除」のメニューが非表示となる事象が発生しました。この 件について原因と回避策について現在(2019/8/16時点)EaseUSにて調査中です。
この事象は別のツールにてパーティションを再構成することで解消しました。ただパーティション削除の操作だけでは未割り当て状態には変わらなかったので何らかの異常な状態になっていたものと推測します。今のところ同じ事象を再現できていないので確認することができませんが、いったんパーティションを復旧させる操作をすることでパーティション削除できる状態に復旧できると推測しています。

USBメモリにパーティションを作成する手順とツール

先にUSBメモリにPCにインストールすることなく利用できるLinuxを構築しました。この際にUSBメモリ上にパーティションを作成して手順を紹介します。

目的;
 「インストールせずにUSBから起動するだけで動作するLinux環境を構築する」これを目的に、次の構成でパーティションを切ります。

パーティション1
 ファイルシステムFAT32
 パーティションサイズ 8GB(Linuxのインストール+Persistentのサイズ)
パーティション2
 パーティションラベル Persistence (この名称のパス名でマウントされる)
 ファイルシステム Ext4
 パーティションサイズ USBメモリの残り全部

●USBメモリにLinuxを構築する際にUSBメモリのパーティションを切る手順

いくつか方法がありますが、まずWinodws10とUbuntuのISOのみでの作業方法をざっと書きます。

1)前準備として暫定版のLinux環境を作成します。Windows10上でUniversal-USB-Installerを使ってUSBメモリをFAT32でフォーマットして、UbuntuをUSBメモリに書き込みます。
 ※フォーマット対象を間違わないように注意してください。間違うと自マシンのHDDが消されます。
  →この部分はUSBメモリでなくDVDでもよいかもしれません。
2)作成したUSBメモリを使ってUbuntuを起動します。起動時のメニューでいくつか選択肢がでます。
つぎのいずれかを選択します。”safe graphics”でない場合、私の環境では2画面でディスプレイ表示できましたが、HDMIのほうがチラつきが激しく不安定でした。
・Try Ubuntu without installing (safe graphics)
・Install Ubuntu (safe graphics)

”Try Ubuntu without installing ”で起動した場合は、起動後に”Ubuntuインストール”を実行します。

上のメニューのどちらでもよいはずですが、左側のメニュー有無の差異により”Try Ubuntu without installing ”で起動したインストラーでは、一部のメニューが画面下にはみ出して動作できない事象が発生しました。”Install Ubuntu”で起動するほうがよいでしょう。

「アップデートと他のソフトウェア」画面では特に設定は何でもよいです。ここで構築するのはパーティションが目的なので、、。
「インストールの種類」画面で、”その他”を選択してください。間違うと自マシンのHDDが消されます。※

インストール先の指定でUSBメモリにパーティションを作成してそこにインストールします。
未フォーマットのUSBメモリの場合はパーティション作成を実行できます。
しかし、一度パーティションを作成すると、この画面の操作では再度パーティションを切りなおすことができませんでした。

インストール先の指定では、USBメモリを選択してください。間違うと自マシンのHDDを上書きし消されます。※

以上の通り、Ubuntuからパーティション作成をすることは可能ですが、パーティションを切りなおせないパターンがあるなど、いろいろかゆいところに手が届かないところがあります。

■どうしても、パーティションを切りなおしたくなったので下のようにツールを利用しました。
■無償版「MiniTool Partition Wizard Free 11」を使ってパーティションを切りなおします
https://www.partitionwizard.com/free-partition-manager.html

●0)準備
 MiniToolのサイトから無償版のファイルをダウンロードしてインストールします。
ファイル名は「pw11-free.exe」でした。インストールするとデスクトップなどにつぎのアイコンができます。これをクリックして起動します。

●1)「 MiniTool Partition Wizard 」のメニューで”ディスク&パーティションの管理”を選択します。

●2)起動した画面でUSBメモリのディスク番号を確認し、下の操作対象の領域をポイントします。

●3)操作した領域にパーティションがすでに切られている場合は、このパーティションを削除します。対象のパーティションを右クリックして”削除”を選択します。

※この時点では、右側のパーティションは削除されように見えていますが、左下の保留中の操作に登録されるだけで、まだ実際には削除はされません。左上の”破棄”をクリックすると次のようにダイアログが表示されるので「はい」をクリックすることで 、保留中の作業を破棄することがきます。

●4)つぎに「パーティション1」を作成します。対象の領域を右クリックして”新規作成”を選択します。

●5)「パーティション1」としてファイルシステムをFAT32、パーティションサイズを8GBに指定してパーティションを作成します。

●6)”パーティション新規作成”で「OK」をクリックすると、つぎの警告ダイアログがでます。「はい」をクリックして継続します。
→補足1参照

●7)つぎにパーティション2を作成します。
  パーティションラベルに”persistence”、ファイルシステムは”Ext4”、パーティションサイズは残りすべてを割り当てます。
→補足2参照

●8)作業内容(保留中の操作)と最終イメージ(右側)を確認し、問題なければ左上の”適用”をクリックします。
→補足3参照

●9)つぎのダイアログが表示されるので、「はい」をクリックします。※ここで”はい”をクリックしてしまうと後戻りできません。間違いないことを確認してください。

●10)保留中操作の適用中は下のダイアログで進行状況を表示します。
 USB 2.0の64GBのUSBメモリの構成で完了までに約2時間かかりました。
→補足4参照

●11)適用が完了するとつぎのダイアログが表示され作業が完了します。

※上の状態で。Windows10のエクスプローラーでUSBメモリの”取り外し”をすると、次のダイアログが表示されます。 「MiniTool Partition Wizard 」がUSBメモリをロックしている状態になっています。

●12) 「MiniTool Partition Wizard 」を終了した後、USBメモリを取り外しします。

以上で、USBメモリのパーティション構成が完了します。 いくつか補足はありますが「MiniTool Partition Wizard 」 無料版は十分使えると考えます。
 下に主に 「MiniTool Partition Wizard 」 の開発者向けのコメントを書きます。

■補足1
「Windowsがリムーバブルディスクの一番目のパーティションのみを識別できるだめ、この新規作成されたパーティションはWindowsで使用できません。」
→この部分だけでもいくつかコメントがあります。
 1) つぎのようにメッセージの日本語表現が不適切な部分があります。「Windowsが 」の”が”は、”は”のほうが適切です。「 識別できるだめ 」の”だめ”ではなく”ため”です。メッセージリソース全体にわたってスペルチェックをかけるか日本語がわかる人にレビューしてもらうことをお勧めします。
 2)それから機能的に不適切なところがあります。Windows10では1つめ2つめともにパーティションを下のようにFAT32でフォーマットすると認識できました。ドライブ文字にX:指定することで正しくX:に割り当てられました。 下の画像ではH:とX:の2つのドライブで認識しています。 このため、「 この新規作成されたパーティションはWindowsで使用できません。 」は不適切ではないでしょうか。
 3)旧バージョンのWindowsでは認識できないのなら、”WindowsXX以前は使用できません”のような表現にしたほうが良いです。

■補足2
「パーティション新規作成」ダイアログで、「パーティションのラベル」を入力した後、ファイルシステムをExt4に変更すると「パーティションのラベル」の文字がクリアされます。ファイルシステムによってはパーティションラベルが入力できないものがあるのはわかりますが、入力枠には上から順番に入力したがるものです。クリアするなら本当にクリアするべき条件に合致しているときだけクリアするようにしたほうが親切です。

■補足3
 「保留中の操作」の番号ですが”2.5”とかは何を意味しているのか分かりにくい、すべて整数で処理順に番号を振ったほうが理解しやすいです。なにか意味を持たせるのであれば、利用者が直感的に分かる表現にしたほうが良いです。

■補足4
「 保留中の操作を適用しています… 」の %の意味は、それぞれの進捗%なので、それ以上でもそれ以下でもないのですが、利用者が一番知りたいのは「あとどれくらい時間がかかるのか」ということです。 現状の%表示ではあとどれくらいかかるのか わかりにくいです。
  FAT32からExt4にフォーマットしなおすのに2時間ほどかかりましたが、FAT32にフォーマットしなおすのに10秒ほどしかかかっていません。Ext4にフォーマットしなおすのに2時間もかかるのは何か余分なことをやっているのか、FAT32にフォーマットするのに必要かもしれない何かを省いているように思われます。工夫することでもう少し早く処理を終わらせることができるように思います。