なんとなく「リリカルなのは Reflection」を観ていたら、張られた結界を「封絶」と呼んでる場面に出くわしたので、たまげた。
・・・それなんていうシャナ？？
結界に、らしい名前つけたいのは分かるけどさ。いくらなんでも「封絶」ってのは、無しだろ。
戦闘中に「ヒートエンドっ！！」とか叫ぶし。
・・・それなんていうドモン・カッシュ？？
どんだけそのまんまパクったら気がすむんだ？・・・もしかして、ネタのつもりなの？
PROMPT="ほにゃらら" の、ほにゃららの中で、
%F{数値}
と記述すると、文字色を変更できる。小文字で書くと色がリセットされる。
%K{数値}
と記述すると、背景色を変更できる。小文字で書くと色がリセットされる。
数値は 0 〜 255 で指定するが、ビットごとにRGB の値が割り当たっているわけではなく、 256 色のカラーパレットが設定されているようだ。
このパレットの色の並びは、先頭の方を見ると、 (XXXXXBGR)2 の「ように」見える並び方をしている（ (00000100)2=(4)10 で青、 (00000010)2=(2)10 で緑、 (00000011)2=(3)10 で黄、のようになっている）が、後ろの方を見ると、この秩序は破綻しているので、ビット指定ではなく、用意されたパレット番号の色を表示しているだけのようだ。
パレットに設定されている値を確認したかったのだが、検索しても、どこにも情報がなかった。代わりに、実際に番号に対する色を表示させているサイトが多数あったので、それらを見ながら設定することにした。
ちなみに、 bash でも 256 表示の色の並びは同じようだ。
URL 入力欄に、
about:config
と入力する。
開いた画面の検索欄に、
app.update.auto
と入力する。
開いた項目はデフォルトで真偽値の true の値を持っているはずなので、項目をダブルクリックし false に変更する。
[コメントの受付は終了しています ]
この記事のリンク元 | 1 |
この記事のリンク元 | 1 |
まず、Build Environment の `ReactOS Build Environment for Unix-compatible Operating Systems Version 2.1.2' から RosBE をダウンロードし中身を展開する。
RosBE-Unix-2.1.2/sources/make.tar.bz2 アーカイブの中にある configure を編集し、
# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
を、
# if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION
と変更し、アーカイブの中身を更新してから、
$ cd RosBE-Unix-2.1.2
$ ./RosBE-Builder.sh
として、表示に従い RosBE のインストール先を指定し RosBE をインストールする（ configure の編集をしないまま RosBE-Builder.sh を実行すると alloca の未定義参照のエラーで RosBE のソースのコンパイルに失敗する。（※１））。デフォルトでは /usr/local/RosBE にインストールされるので、その場合は前もって su で root 権限をもたせておく。
次に、
git clone https://github.com/reactos/reactos.git
を実行し、reactos のソース環境をクローンする。
それから、
$ cd RosBE
$ ./RosBE.sh
のようにして RosBE のシェルに入り、
$ cd reactos
$ ./configure.sh
とすることで reactos/output-MinGW-i386/ 以下が作成される。
この後、
$ cd output-MinGW-i386
で reactos/output-MinGW-i386 の中に移動するが、そのまま ninja bootcd を実行したのでは、 gcc がコンパイル中にプリコンパイルヘッダのエラーが起きビルドが通らない（※２, ※３）ので、 reactos/output-MinGW-i386/CMakeCache.txt を編集し、
PCH:BOOL=1
を、
PCH:BOOL=0
のように変更してから、
$ ninja bootcd
とすることで ReactOS のブートＣＤが作成される。
VMware Player をインストールして使用する場合に、 `Create a New Virtual Machine' から guest OS の iso イメージを読み込み起動しようとしたとき、 modconfig がモジュールを更新しようとするときがある。その際に vmmon のコンパイルのところで止まってしまい実行出来なかった。
止まってしまう原因はいくつかあって、まず、 vmmon, vmnet のソースコードの一部が最近のカーネルと不整合を起こしているためコンパイル時にエラーとなることと、 script の実行時にもエラーが出ること、そして、コンパイルして作成されるカーネルモジュール vmmon.ko, vmnet.ko に署名がされていないため起動に失敗することだ。
まず、カーネルコードとの不整合については、 Michal Kubeček 氏の GitHub に修正版のソース一式を挙げてくださっているので、そちらを使用させていただく。
sudo /etc/init.d/vmware stop
としてサービスを停止しておいてから、氏の GitHub の INSTALL に記述されている通り、
wget https://github.com/mkubecek/vmware-host-modules/archive/player-14.1.1.tar.gz
tar -xzf player-14.1.1.tar.gz
cd vmware-host-modules-player-14.1.1
make
make install
としてやれば vmmon.ko, vmnet.ko の修正版がインストールされる。（ 14.1.1 のところは使用する VMwarePlayer のバージョンに置き換える。ただし、氏の GitHub に修正版が上がっていることが前提。）
これで vmmon, vmnet のコンパイル時のエラーは解消される。
このとき、 make したとき、
./scripts/***: *** 行: printf: 0x十六進数ダンプ:: 無効な十六進数です
といったエラーも出るが、これは LANG=C make とすることで解消できる。
この後、 make install した後そのまま、
sudo /etc/init.d/vmware start
とした場合、
Starting VMware services:
Virtual machine monitor failed
Virtual machine communication interface done
VM communication interface socket family done
Blocking file system done
Virtual ethernet failed
VMware Authentication Daemon done
のように２つのモジュールの起動に失敗するが、これは UEFI の validation 機能が有効になっている場合に更新したカーネルモジュールに署名がされていないためなので、
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /*/*.ko
のようにして vmmon.ko, vmnet.ko に署名してやると起動できるようになる。 MOK.priv, MOK.der は事前に作成しキーを登録しておかなければいけない。
VMware が自動的にモジュールを更新しようとしたとき、この署名の操作をしないため、 UEFI の validation が有効になっていると更新に失敗するはずだ。（ VMware はなぜこの問題に対応しないのだろう？ ）
キーワード: VMware Player modconfig