2020年5月31日日曜日

CloudReadyでChromiumOSをインストール(サブノートPCをChromeBook化)する

4年ほど前にAcerサブノートPCをChromeBook化するのにかなり苦労をしたのですが、ここへ来てChromeBookへの注目度が高まってきたので、久しぶりにメンテナンスをしてみようかと思い立ちました。そもそも、ChromeOS自体は公開(無償配布)されておらず、ChromeBookを使いたいならChromeBookを購入するのが一番の近道です。自分でChromeBook(のようなもの)を作ろうと思ったら、無償で配布されているChromiumOSをインストールして使うしかありません。これがなかなか厄介で、簡単に使えるとは言い難いものです。そこで、今回はCloudReadyを使ってみることにしました。

必要なのは、CloudReadyの32bit版です。ChromeBook化しようとしているサブノートPCが32bitにしか対応していない(CPUは、Intel Atom N280を搭載)からです。残念なことにCloudReadyのWebサイトでは、32bit版のサポートは終了していて配布も行われていません。いろいろと探し回った結果GetMyOSというサイトにCloudReadyの32bit版が残っているのを見つけました。早速これ(.zipファイル)をダウンロードして、サブノートPCへインストールすることにしました。

インストール方法は、Easy Innovation Zoneの「CloudReady Home のインストールと設定」を参考にしました。使ったのは、Google ChromeブラウザとGoogle Chrome上で動く「ChromeBookリカバリユーティリティ」です。両方ともGoogle検索ですぐに見つけることができました。(先にGoogle Chromeをダウンロード&インストールしておいてから、Google ChromeでChromeBookリカバリユーティリティを検索して「chromeに追加」ボタンでインストールします)ダウンロードしておいたCloudReadyの.zipファイルをリカバリユーティリティで読み込みます。「歯車(ギア)」マークをクリックするとメニューが表示され、「ローカルイメージを使用」を選択することでダウンロードした.zipファイルを読み込むことができるようになります。(.zipファイルは解凍する必要はありません)このあと、8GB以上のUSBメモリを挿してインストールUSBメモリを作ります。少々時間はかかりますが、待つだけですので以前のような苦労はありませんでした。

出来上がったUSBメモリをサブノートPCに挿して起動します。難なく起動して設定画面が表示されました。どうやら、USBメモリからの起動で使い続けることもできるようでしたが、設定完了後の画面からHDDへのインストールを選択して作業続行。32bit版のサポートが終了していることを警告しているらしきものが出てきたのですが、完全に無視をして作業を続けました。長くなりそうなのでしばらく放置していると、いつの間にかインストールが終了していました。起動してGoogleのアカウントでログインすると、無事にChromiumOSが起動しました。デスクトップに表示された「ChromiumOS 76.3.33」というのが今回使った32bit版のバージョンなのだと思います。

古いPCを再生させることにどれだけの需要があるかはわかりませんが、ChromeBookを試してみたいけど、既にPCがあって製品のChromeBookを買うほどではないという状況の人たちには、USBメモリから起動するというのは需要がある気がします。(学校現場では、この行為が制限されている場合が多々ありますが…)私のように古いPCを不良在庫レベルで持っているような者にとっては、32bit版のサポート終了が痛く思われます。これからも、細々とではありますがChrome(Chromium)OSで何ができるか試してみたいと思っています。

2020年5月10日日曜日

カブトムシの世話(2020春)〜蛹化前のギリギリのタイミングで

新型コロナウイルス感染症拡大防止のための緊急事態宣言が延長され、まだまだ予断を許さない状況もあり、Stay Homeということで、GWを含めた休日はできるだけ外に出ないようにしておりました。そんな中、ふと「カブトムシの世話をする時期はいつ頃だったかな?」と気になり、このブログを見直して、概ねGWの時期には夏前の世話をしていることを確認しました。(あれもこれも変更に次ぐ変更で、自分の中の季節感が狂ってしまっています)冬眠から目覚めた時期は、カブトムシたちが蛹化に向けた準備に入るため、最後にしっかり餌(クヌギと腐葉土)を与えて蛹化を待つことになります。
#冬眠前にしっかり太らせておくと良いようです。

前回の世話から約半年、この間にも、追加で腐葉土を入れたり加水したりと軽い世話をしていましたが、本格的にひっくり返して状態を確認しながらマットの交換を行いました。2017年から飼育マットをクヌギマット&腐葉土にしたのですが、この3年間でノウハウがだいぶたまってきました。腐葉土は、カブトムシの栄養源としては効率が悪く、かさばるけれども消費も多いということや、カブトムシ自体もこぶりなものになりやすいということがわかりました。それを補うためにクヌギマットを併用したり、朽木を年に7〜8本くらい入れて補ったりしています。そのためか、全体の1/3程度の個体は、かなり大きく育っています。

腐葉土自体の分解が進み、クヌギよりも早く黒土化してしまうということもわかりました。カブトムシのフンは、黒土そのものなのですが、細かく粉砕する前は、粒ガムよりちょっと小さいくらいの大きさ・形をしています。(クヌギばかりで飼育するとクヌギの匂いがしますが、腐葉土を混ぜているので土の匂いです)これを花の肥料として使っているのですが、腐葉土飼育になってからは、フンの粒だけでなく腐葉土が黒土化したものも出てしまうので、入れ替え作業が大変です。今回は、コンテナの半分ほどのフンと黒土を取り除き、クヌギマットと腐葉土を加水して敷いたところに使えそうなマットとカブトムシの幼虫を戻しました。加水したクヌギマットと腐葉土は、蛹室づくりのことも考えて予め少しつき固めておきました。カブトムシの幼虫は、69頭いました。(死骸が見つかったのは、1頭だけでした)

これで何とか蛹化前の世話を済ませることができました。あとは、夏に向けて約1ヶ月半ほど成虫になるのを待つだけです。新しい職場では、今の所カブトムシも花の肥料も必要な感じがしませんが、何かできることはないかと思っているところです。

2020年5月4日月曜日

macOSとLinux Mint 19.3でSambaの設定(ファイアウォールを含む)をしてmacOSや別のLinux機から共有フォルダを使えるようにするまでの試行錯誤

macOSがCatalinaになって、ファイル共有の動きがイマイチな感じになっていました。AFP(Apple Filing Protocol)で共有フォルダを開くと、macOSジャーナリングでフォーマットしたHDDの中身が見えなくなってしまったのです。これにはかなりパニック状態になりました。なぜなのかわからず、長いこと試行錯誤しました。

ドライブのフォーマットの問題かと思い、exFATでフォーマットしてやってみました。これで、中身は見えるようになりましたが、ファイルを開くことはできても保存がうまく行かないなどのアクシデントがありました。仕方がないのでSMB(Server Message Block)で開き直してみると、exFATでは、アプリケーションが開いたファイルの位置を見失う状態になりました。ならばということで、macOSジャーナリングでフォーマットしたドライブをSMBで開いてみました。すると、中身も見えるし問題なく使えるようになりました。いつの間にか、macOSのファイル共有は、SMBが基本になっていたのですね。
#どうやら、FAT系フォーマットのドライブの扱いが、何か変わったのかなという印象。

ならばと思い、先日設定をしたHTPCIntelCeleron J1800を載せたGIGABYTEGA-J1800N-D2H)のSamba(SMB)設定を強化すべく、設定をいじることにしました。Sambaは既にインストールしてあるので、HTPCのホームディレクトリが共有できるようになっています。「/etc/samba/smb.conf」には、以下のように書き込んであります。
[homes]
   comment = Home Directories
   browseable = no
   read only = no
   valid users = %S
ここまでの設定で使えることは使えるのですが、最低限のセキュリティとして、ファイアウォールは必須と考えてLinux Mint 19.3のファイアウォールの設定をONにしました。すると、HTPCにアクセスすることができなくなりました。macOSとは違って、ファイル共有とファイアウォールの設定は、自動的に関連付けられてはいないのです。そのため、ファイアウォールの設定をいじらなければななりません。先程、ファイアウォールをONにした設定ツールからルールを追加します。

Linux Mintの「ファイアウォール設定ツール」を開いて「ルール」タグの窓の下方にある「+」ボタンを押して、以下の設定を追加します。
ポリシー:Allow
方向:In
カテゴリー:すべて
サブカテゴリー:Service
Application:Samba
ここまで設定したら「追加」ボタンを押します。すると、自動的にルールが書き込まれるので、これで設定が完了(「閉じる」ボタンを押して良い)します。ここまでやった後、iMacMacBook Proからアクセスしてみましたが、問題なくHTPCにアクセスすることができるようになり、ホームディレクトリが使えるようになりました。

ついでに、別のLinux機(うちの場合は、多くはMintで動いているけれども、様々なLinux機でも同様です)からアクセスできるようにしてみました。次のようにクライアントの設定をします。
$ sudo apt install cifs-utils
cifs-utils」は、Windowsのネットワークに入るためのもので、必ずしもSamba専用というわけではありません。Windowsでファイルサーバを運用しているところで、Linuxからアクセスする場合にも、「cifs-utils」を使います。使い方は難しくありませんが、ちょっとしたコツが必要です。(Linuxユーザなら特に問題はないでしょう)

はじめに共有するフォルダをマウントする場所(マウントポイント)を用意します。
$ sudo mkdir -p /mnt/〈任意の名前〉
このコマンドで、/mntフォルダの中に、任意の名前のフォルダをつくるというイメージです。マウント後は、このフォルダの中に共有先のファイルやフォルダが見えるようになります。続いてマウントコマンドで共有先をマウントします。
$ sudo mount -t cifs -o username=〈username〉,password=〈password〉 //〈serverのPC名〉/〈共有フォルダ名〉 /mnt/〈任意の名前〉
〈username〉と〈password〉は、Sambaを動かしているサーバ側で設定したものを入力します。〈serverのPC名〉と〈共有フォルダ名〉も、サーバ側で設定したものです。これで、/mnt/〈任意の名前〉に共有先のフォルダがつながってファイルやフォルダの共有ができるようになります。
#「Narrow Escape」のLinuxMint 19: SMBクライアントのcifs-utilsをインストールするを参考にしました。

これらの一連の操作をシェルスクリプトとして保存しておいて、起動と同時に自動で走らせるという方法もありますが、セキュリティ上どうなのかという心配があります。(やる場合は、自己責任で)

2020年4月29日水曜日

調子の悪いMacBook Pro(Mid 2012)からMacBook Pro(2019 Two Thunderbolt 3 ports)へ移行作業をする

新しいMacBook Airの方が話題になっていますが、そんなこととはおかまいなしで、ちょっと前にMacBook Proを買ってしまった私は、仕事の合間を縫ってセットアップをすることにしました。今までは、壊れてから買い替えるパターンが多かったMacBook系のマシーンでしたが、今回は、調子は悪いものの動かないという状態ではないので「移行アシスタント」で使用環境をそのまま移行してみることにしました。
#だいぶ以前にiMacで経験済みですが…。

まずは、新しいMacBook Proのセットアップを進めます。言語の設定やネットワークの設定などを終えたところで、「移行アシスタント」を使うかどうかという選択肢が出てきます。ここまでやったら、今度は古いMacBook Proの電源を入れて、同じく「移行アシスタント」を起動します。ここでは、「別のMacへ」を選択します。古いMacBook Proは安定していないことが買い替えの理由でしたが、この作業中に2回ほどフリーズしました。最初は、「移行アシスタント」が起動せず、黒い画面のまま固まりました。2度目は、全ての移行が終わって再起動しようとしたところでフリーズ。既に新しいMacBook Proへの移行が完了していて、動作確認ができていたため事なきを得ましたが、きちんと移行ができているのか心配になる状態でした。(ヒヤヒヤしました)

その後は、古いMacBook Proも見違えるほど普通に動くようになってしまいました。アプリケーションソフトがきれいに整理整頓されていたり、新しいmacOSで動かなくなっているものが消えてなくなっていたりといった状態が確認できました。いろいろ動作の邪魔をしていたものが綺麗サッパリなくなって身軽になったのかもしれません。「移行アシスタント」には、移行に邪魔なものを整理したり正常に戻したりする機能があるのかもしれませんが、正確なところはわかりませんでした。
#移行のために古い方も使っていると、やはり次第に調子が悪く、動作が不安定になっていきました。両方使えるかもとも思いましたが、やめた方が良さそうです。

ちょっと意外だったのは、Movies、Music,Picturesの3つのフォルダの中身が引き継がれなかったこと。データ量が多かったので、USB接続の外付けSSDドライブを使ってデータを移動させました。(ついでにいらないものを捨てて、すっきりしました)もしかすると、iCloudで共有しておけばこんな手間をかけなくてもよいのかもしれません。

最後に、メーラーとして愛用しているThunderbirdの移行を行いました。これがちょっと面倒くさい。まず、Finder(macOSのデスクトップ)の「移動」メニューをoptionキーを押しながらクリックすると、プルダウンメニューの中に「ライブラリ」というメニューが現れます。これを選択して開くと、その中に「Thunderbird」という名前のフォルダがありますので、「Thunderbird」→「Profiles」とたどって、「.default」という文字列が含まれるフォルダをコピーして、新しい環境の同じ場所へ移動します。今回は、「.default」が付いているフォルダを、USBメモリに保存して新しいMacBook Proに移動しました。
#この方法は、MacからWindows等別のOS間でも使えるようです。

ここで1つ問題が発生。この新旧MacBook Proの移行作業を数日かけて行っていたため、無意識的に古いMacBook ProのThunderbirdをアップデートしていて、新しいMacBook ProのThunderbirdとバージョンが合っていない状態になっていました。この状態だと、データのバージョンが違うので引き継げない旨のメッセージが出て、設定やメールの内容などが引き継げません。そのため、Thunderbirdのバージョンを揃えておく必要があったのでした。新しいMacBook ProのThunderbirdをアップデートして、無事に作業を終えました。

これでようやく実用的な状態にはなりました。新しいMacBook Proの使い心地ですが、薄さの犠牲となった打鍵感と使い所がイマイチなTouch Barの問題はありますが、その他の操作については古いMacBook Proのときのようなつまずき感やフリーズがないので快適です。速度も申し分ない。USB-C機器を揃えていないので、今まで通りに使用するにはちょっと工夫は必要ですが、Appleストアで使える18,000円クーポンがもらえたので、USB-AやHDMIに変換する(ついでにSDカードも読み込める)コネクタや純正のDVDドライブを購入して使っています。新macOS Catalinaへの対応が遅いソフトウエアが多くて(というより、Macのソフトウエアの需要が少なすぎるor対応が難しい?)完全に今までと同じことができるとは言えないのですが、Linuxで動くPCを使うなど様々なアプローチでより快適な作業環境を実現したいと思っています。

2020年3月15日日曜日

Linux版Scratch 1.4で作ったプログラムがScratch 3.0でコードが見えない現象(謎の文字化けが起こる)を検証する

前回までに、常用しているLinux MintWine上で、Windows版Scratch 1.4を動かして、Scratch 3.0でスクリプト(コード) が見えなくなる原因を突き止めました。Linux版Scratch 1.4では直接日本語入力ができず、テキストエディタなどの別のところで日本語文字列を作り、それをコピペして日本語を入力するという手順を踏まなければなりません。この過程で変換不可能な文字列(これが何かはわかりませんでしたが)が紛れ込み、これをScratch 3.0で開くとコードが見えなくなることがわかりました。Scratch 2.0は、この不具合を解消する処理をしているらしく、Scratch 1.4で作ったものを2.0で読み込んで保存もしくはアップロードすると、3.0でも問題なくコードが見えるようになるのでした。

検証した環境と結果は以下のとおりです。(改行コードのせいもあると考えて、改行を含むものと含まないものとを並べてみました)(1)アルファベットのみ、(2)日本語(改行なし)、(3)日本語(改行あり)の順です。

Linux Mint 19.3 Tricia(MATE 64bit)
〈Wine上のWindows版Scratch 1.4で見ると…〉

Raspbian 9.8
〈Wine上のWindows版Scratch 1.4で見ると…〉

Puppy Linux 5.1.1 Wary(日本語版にScratchなどを入れたものを使用)
〈Wine上のWindows版Scratch 1.4で見ると…〉

今回は、Raspbianだけ不具合がありませんでした。MintとPuppyでは、改行ありだと明らかに見た目がおかしいので、気づくのではないかと思います。とは言え、改行なしでも文字化けが含まれてしまうのですが。

今後のScratch 1.4での開発は、Wine上のScratch 1.4か、RaspbianのScratch 1.4で行うようにするか、日本語を使わないようにするかという選択になりました。

Linux MintのWineでWindows版Scratch 1.4を動かす

Macの新しいOS(macOS Catalina 10.15.x)でScratch 1.4が動かないため、Linux MintPuppy Linuxなどの力を借りて、Scratch 1.4での開発をしている続きです。先日、Linux MintのScratch 1.4で作ったプログラムが、Scratch 3.0上で「コードが見えない」という不具合を発見しましたが、全てダメということではなく、どうやら日本語の扱いに問題があるということがわかってきました。

毎度のことながら、@abee2さんに助けていただき、Windows版のScratch 1.4で開いてみると「化けた文字」が含まれていると教えていただきました。自宅にあるパソコンは、デスクトップ・ラップトップ合わせて数十台にもなりますが、残念(意図的)ながら(我が子の学習用以外で)Windowsで動くものはありません。そこで、MintのWine上でWindows版Scratch 1.4を動かしてみてはと勧められたので、やってみることにしました。幸いなことに、別の需要があってWineはインストール済みでした。(「ソフトウエアの管理」からインストールしました)
#他にも、PlayOnLinuxもインストール済みですが、今回はあまり関係がありません。

Windows版Scratch 1.4のインストーラーをダウンロードして、Linux Mintでダブルクリックすると、難なくインストール作業が始まり、無事に完了しました。後は起動するだけ。ちょっとドキドキしましたが、無事にWindows版Scratch 1.4が起動しました。しかし、日本語が表示されず全て豆腐(□)になっています。これでは不具合を確認することすらできません。そこで、過去にWineの設定をしたときのことを思い出しました。Wine 4.0以降は、割と日本語表示が簡単になったという噂を目にしましたので、過去の経験を頼りにやってみましたが、うまくいきません。「Wine設定」自体がすべて日本語表示になっているし、デフォルトでインストールされている「メモ帳」もメニューの日本語表記や入力が日本語でできるというのに、Scratchだけは頑なに日本語を受け付けてくれないのです。

もう打つ手はないのかと絶望感に苛まれつつも、これはScratch 1.4自体のフォントの設定が問題なのではないかと考えました。過去の記憶を頼りに、フォントの設定を変えることができたような気がしてきたのです。localeの.poファイルにフォントの設定を書き込めることを教えていただき、過去にそんな設定をやったことを思い出しました。ja.poとja_HIRA.poの以下の部分を書き換えました。

〈変更前〉
# Font to use on a Windows system
msgid "Win-Font"
msgstr "Tahoma"
〈変更後〉
# Font to use on a Windows system
msgid "Win-Font"
msgstr "Takaoゴシック”
日本語フォントに何を使っているかによって設定が変わると思いますが、私の環境(Linux Mint)では「Takaoゴシック」が入っているためこのようにしました。これで、問題のあった.sbファイルを開くと、日本語文字列の後に豆腐(□)が見えるようになりました。デフォルトで日本語表記になっているもの(スプライトの名前など)には、特に問題がないため、Linux版Scratch 1.4で日本語入力ができないことと関係がありそうだと当たりをつけました。次は、なぜこのようなものが混じってしまうのか検証して行きたいと思います。

【追記】Windows版Scratch 1.4で日本語に豆腐(□)が交じる現象が起きる環境を特定しました。(2020.3.15)
 「Linux版Scratch 1.4で作ったプログラムがScratch 3.0でコードが見えない現象(謎の文字化けが起こる)を検証する」

2020年2月23日日曜日

Scratch 1.4で作ったプログラムをScratch 3.0で読み込んだときの不具合を回避する

Macの新しいOS(macOS Catalina 10.15.x)でScratch 1.4が動かないため、Linux MintPuppy Linuxの力を借りて、Scratch 1.4での開発を続けているところです。先日、Linux Mintで作ったプログラムをScratch 1.4の機能を使って共有(アップロード)したところ、Scratch 3.0上で「コードが見えない」という不具合に遭遇しました。そこで、どんなときに不具合が発生するのかを検証し、解決を試みることにしました。

まず、この不具合が発見されたプログラムについて、LinuxのScratch 1.4からアップロードしてLinuxのFirefoxとMacのFirefox、WindowsのEdgeでScratch 3.0(オンライン)を開いてプログラムを見た場合も、同じく3つの環境でScratch 3.0(オンライン)を開いてプログラムのファイルを直接読み込んだ場合も、いずれもコードが表示されませんでした。Scratch 3.0(オフライン)についても、Linux Mint、Mac、Windowsで試してみましたが、やはり状況は変わりませんでした。

そこで、Scratch 1.4とScratch 3.0(オフライン)で、スクリプトやコードの違いを検証することにしました。問題のないものと問題が起きているものを見比べてみましたが、細かな点で差はあるものの、コードが見えない不具合を抱えているプログラムと問題がないプログラムとの大きな差を感じませんでした。

いろいろ考えながら検証しているうちに、Linux Mintからプログラムをアップロードしようとすると、Scratch 1.4が落ちるという現象が起きるようになりました。さらに困ったことになりました。仕方がないので、同じプログラムをRaspberry PiRaspbian)からアップロードを試みましたが、Scratch 1.4は落ちないものの、エラーを吐いてアップロードが途中で止まってしまいました。Puppy Linux改でもやってみましたが、結果は同じでした。エラーメッセージは、Raspbianで「Failed: INVALID_REQUEST…」、Puppy Linux改で「Failed: address not found」となっているので、どうやらこの作業の間に、Scratch 1.4からアップロードする先が何らかの理由で閉鎖された(一時的なものかもしれません)のではないかと推察しました。

これ以上、問題を検証することが難しくなりました。

仕方がないので、MacのScratch 2.0(オフライン)で開くとどうなるか試してみました。すると、不具合のあったプログラムのスクリプト(コード)が問題なく表示されました。さらに、このScratch 2.0(オフライン)からアップロードすると、Scratch 3.0(オンライン)でもコードが見えるようになりました。同じくScratch 2.0(オフライン)でプログラムを保存すれば、Scratch 3.0(オフライン)で開いてもコードが見えます。とてもややこしい状態ではありますが、Scratch 1.4で作ったプログラムで不具合があっても、2.0で読み込んでアップロードすれば、3.0でもコードが表示されることがわかりました。

こうなると、今後、Scratch 1.4を使い続けることが困難になってきていることが実感できました。とは言え、3.0への完全移行が得策と言えるかどうか、頭を悩ませています。

【追記】Scratch 2.0(オンライン)の頃に1.4からアップロードしていたものは、現在の3.0(オンライン)でもコードが見えるけれど、現在のScratch 3.0で直接1.4の.sbファイルを開いてもコードが見えなくなるものがある、ということがわかってきました。1.4から2.0になる過程で、コードの仕様に関する何らかの変更があり、2.0は、その変換を行っているものと推察しました。また、3.0も公開から今日に至るまで、仕様変更されている可能性があるのかなとも思いました。(2020.3.8)

【追記】この現象は、Linux版Scratch 1.4での日本語の扱いの問題であることがわかりました。Linux MintでWineを動かして確認しました。(2020.3.15)
「Linux MintのWineでWindows版Scratch 1.4を動かす」

【追記】Windows版Scratch 1.4で日本語に豆腐(□)が交じる現象が起きる環境を特定しました。(2020.3.15)
 「Linux版Scratch 1.4で作ったプログラムがScratch 3.0でコードが見えない現象(謎の文字化けが起こる)を検証する」