2020年9月26日土曜日
散髪
2020年9月8日火曜日
散髪
2020年8月14日金曜日
散髪
クソ暑いのと感染リスク低減を踏まえ、自宅で散髪する事に(^^;
通販でバリカンを購入。
#折角、国内家電メーカ製を選んだのに、届いたらMade in Chinaだった(--;
#もう少し高いのにしたら、国内製だったのかな?
ま、ともあれ、説明書通りに一晩充電してから、注油して初使用。
下の方は6mmで刈上げ、上の方は12mm。トップはハサミで切ってもらった。
初めてにしてはなかなかいい感じです。
当分、これでしのぐかなぁ。
2020年8月13日木曜日
macosでの/etc/fstabの編集
$ sudo su
# vifs
#
# Warning - this file should only be modified with vifs(8)
#
# Failure to do so is unsupported and may be destructive.
#
UUID=BA80B0B6-B49B-47A4-8C9F-XXXXXXXXXXXX /Users/shibata apfs rw,auto
2020年8月9日日曜日
MacBook Pro(late 2008)でCatalinaのIMEを動かす
ずっとmacos patcherのお世話になりながらHigh Sierraで動かしていたMacBook Pro(late 2008)だが、Xcodeなどのapple謹製ソフトがインストール出来なくなり困ってきた。
#実は以前、Mojaveにしてみたのだが不安定でどうにもならなかったので、
#High Sierraに戻していた。
駄目元でCatalinaにしてみた(^^;
【全体の手順】
1.まずはTime Machineでバックアップをとる。
事前にできるだけ不要なファイルは消しておく。
2.macOS Catalina Patcherをダウンロードし、
手持ちのUSBメモリをインストールメディアにする。
3.手順通りにmacos Patcherで作成したインストールメディアで起動させ、
内蔵HDDにCatalinaをインストールする。
#と、スンナリいっているいるように書いているが、postinstallのpatchが失敗して
#駄目元で内蔵HDDからCatalinaを起動させた後にpostinstallを行なった。
#Catalinaの起動も30分ぐらいかかり、けっこう待たされた。
4.内蔵HDDからCatalina起動後、もう一度インストールメディアで起動して
postinstall patchを実行する。
5.日本語入力がおかしくなるので、MojaveのIMEを移植する。
6.再起動すれば、出来上がり。
肝は上記の5である。
ネットを探すと、macOS Catalina Patcher 不具合情報と解決策という、ありがたいサイトがあった。
もう一台のmacをたまたまMojaveで動かしていたので、そちらから関係するファイルを持ってきた。
#これで良かったんだろうな(^^;
【移植したファイル】
下記の青文字がMojaveから移植したファイル。
同じく赤文字はCatalinaにあったファイルのバックアップ。
sh-3.2# pwd
/usr/lib
sh-3.2# ls -l libmecab*
-rwxr-xr-x@ 1 root wheel 1596512 8 9 18:07 libmecab.1.0.0.dylib
-rwxr-xr-x@ 1 root wheel 1596512 8 9 18:07 libmecab.dylib
-rwxr-xr-x 1 root wheel 812464 8 6 09:49 libmecab.dylib.bak
-rwxr-xr-x@ 1 root wheel 4820080 8 9 18:07 libmecabra.dylib
-rwxr-xr-x 1 root wheel 2881600 8 6 09:50 libmecabra.dylib.bak
sh-3.2# pwd
/System/Library/Input Methods
sh-3.2# ls -l JapaneseIM.*
JapaneseIM.app:
total 0
drwxr-xr-x@ 9 root wheel 288 2 23 2019 Contents
JapaneseIM.bak:
total 0
drwxr-xr-x 9 root wheel 288 6 6 15:27 Contents
sh-3.2# pwd
/System/Library/PrivateFrameworks
sh-3.2# ls TextInput*
TextInput.framework:
Resources TextInput Versions
TextInput.framework.bak:
LanguageIntelligenceTrialDefaults.pb TextInput
Resources Versions
TextInputCore.framework:
Resources TextInputCore Versions
TextInputCore.framework.bak:
Resources TextInputCore Versions
TextInputMenuUI.framework:
Resources TextInputMenuUI Versions
【移植のちょっと詳細】
【移植元作業】Mojave側
- ターミナルを開き、suでrootになる
- 上記の青文字のファイルを、cp -a でどこかのフォルダにまとめる
- zipで固めて、移植先マシンにコピーする
【移植先作業】Catalina側
- コピーされたzipを解凍し「何処かのフォルダ」に置く
- 移植先をインストールメディアで立ち上げる
- 移植先のフォルダで、mv hoge hoge.bakする
- 移植先フォルダに 「何処かのフォルダ」からcp -aする
- コピーしたファイルに対してchown -R root:whell hogeする
- 上記3.〜5.を対照ファイル分、繰り返す
【ご参考情報】
2020年8月8日土曜日
mongodb connector for business intelligence
mongodb connector for business intelligence
って、mongodbをODBCぽいSQL-DBに見せかけるラッパーかな。
https://www.mongodb.com/products/bi-connector
https://docs.mongodb.com/bi-connector/master/
2020年8月7日金曜日
RP3B+のルートパーティションをnfsでマウント
絶不調のでお蔵入りにしていたRaspberry Pi 3B+だが、捨てるには惜しいので、不安定なμSDカードをできるだけ使わない方法で安定するかどうかを検証すべく、以下を行なった。
【USB経由でSDカードを使う】
- USB経由でSDカードを使うようにする
/も/bootもSDカードのまま。ただし、sd→USBアダプタを使って起動させる。
何も設定しなくても、RP3B+は標準でUSBブートするようで、上記はあっさり動いた。
上記でも以前より安定して動いたような気がする。
しかし、もう一歩進めて、下記のようにした。
【USB経由で/bootさせ、/パーティションはnfsでマウントする】
- USB経由のSDカードは、/bootだけにする(ほぼread onlyになる)
- /ファイルシステムは、隣に並んでいるRaspberry Pi 4Bをnfsサーバにして、
そこからのマウントにする
(RP4Bのストレージは、USB3経由でマウントしているSSDなので
SDカードよりは性能も耐久性も良いだろうと) - 具体的な方法はNFS Root on Raspberry Pi 4 そのままでいけた。
(上記ページはraspbianの例もubuntuの例もあり、非常に助かる)
次にやるかもしれないのは、下記。
【PXEブートを使い、tftpで/bootをマウントさせ、/はnfsでマウント】
これができたら、不安定なSDから完全におさらばできる。
それらしい情報は下記にあるので、不安定さが解決しな時には試してみよう。
Raspberry Pi 3 でSDカードなしのネットワークブートをする
以上(^^;