mieki256's diary

「fooocus インストール」でググったら解説記事が結構あった。ありがたや。

_【西川和久の不定期コラム】次世代Stable Diffusion(SDXL)をWindows上で一発で使用可能にする「Fooocus」 - PC Watch
_Fooocusのインストール【web UIとComfyUI以外の選択肢】 | ジコログ
_SDXLを手軽に扱える「Fooocus」のインストール方法・使い方まとめ!簡単操作でハイクオリティな画像を生成しよう | くろくまそふと
_Fooocus のインストール,Stable Diffusion XL (SDXL) による画像生成の実行(Fooocus,Stable Diffusion XL,PyTorch,Python を使用)(Windows 上)
_Fooocus: 超軽量でシンプルイズベスト、なSDXLクライアント|かいりん
_Stable Diffusion - Fooocusの概要と導入方法・使い方 | 紫雲雑想

Fooocus_win64_1-1-10.7z を入手して解凍。

_lllyasviel/Fooocus: Focus on prompting and generating

以下のモデルデータを入手して、Fooocus\models\checkpoints\ に置いた。

• sd_xl_base_1.0_0.9vae.safetensors
• sd_xl_refiner_1.0_0.9vae.safetensors

_stabilityai/stable-diffusion-xl-base-1.0 at main
_stabilityai/stable-diffusion-xl-refiner-1.0 at main

run.bat を実行したら、必要なファイルをDLした後、画像生成を指示するためのUI画面がWebブラウザで開かれた。ちなみに今回は D:\aiwork\fooocus\ にインストールしておいた。

Stable Diffusion web UIと違って、Webブラウザが自動で起動するっぽい。

1152x896 の解像度でお姉さん( a girl, japanese, ) を生成してみた。

最初の生成時は、6GB以上もあるモデルデータをHDDからロードするので、かなり時間がかかる。タスクマネージャでパフォーマンスを確認したら、HDDがずっと100%。9分ぐらい過ぎたあたりで、ようやく100%状態が終わった。SSDに置いておけばもっと速くなるのだろうけど、自分の環境はSSD側の空き容量が厳しいので…。

生成を指示して10分ぐらい経ってから、モデルデータのロードその他の処理が終わったようで、そこからようやく生成処理っぽいものが走り始めた。

画像を1枚生成するのに、4〜5分ほどかかった。それでもちゃんと、それらしい画像を生成してくれた。VRAM 6GB でも、たしかに動いた…。しかし、さすがに時間がかかるなと。今時のGPUが欲しくなるなあ…。

手のデプスマップを上書きしてくれる拡張機能、depth-lib をインストールすると、本体が dataset 云々のエラーを出して動かなくなることに気づいた。

_jexom/sd-webui-depth-lib: Depth map library for use with the Control Net extension for Automatic1111/stable-diffusion-webui

以下の修正をすればエラーが解決するらしいけど…。

_Quick fix for KeyError: 'dataset' - Issue #36 - jexom/sd-webui-depth-lib

venv\Lib\site-packages\gradio_client\serializing.py の COMPONENT_MAPPING という辞書リストに以下を追加せよ、と書いてあるのかな。

"dataset": StringSerializable,

また、この拡張機能は放置気味なので fork した人が居るらしい。

_New fork with additional features - Issue #39 - jexom/sd-webui-depth-lib
_wywywywy/sd-webui-depth-lib: Depth map library for use with the Control Net extension for Automatic1111/stable-diffusion-webui

とりあえず fork版をインストール、かつ、前述の修正をしたところ、エラーが出ない状態になった。

Ruby 1.8 時代に標準で添付されていた win32api を使って試してみた。

環境は以下。

• Windows10 x64 21H2
• Ruby 1.8.7 p330 i386-mswin32
• Ruby 1.9.3 p551 i386-mingw32

Ruby 1.8 / 1.9 の両方で動作した。

処理内容は、1秒毎に数値を 0 〜 9 まで出力する。また、起動時に、既にどこかで同じスクリプトが動いてたら即座に終了する。

_03_mutex_win32api.rb

require "Win32API"

create_mutex = Win32API.new("kernel32", "CreateMutex", "llp", "l")
release_mutex = Win32API.new("kernel32", "ReleaseMutex", "l", "l")
close_handle = Win32API.new("kernel32", "CloseHandle", "l", "l")
get_last_error = Win32API.new("kernel32", "GetLastError", "", "l")

MUTEX_NAME = "ruby_win32api_mutex_sample"
ERROR_ALREADY_EXISTS = 183

mutex = create_mutex.call(0, 1, MUTEX_NAME)
err = get_last_error.call()
puts "Mutex : #{mutex}"
puts "GetLastError : #{err}"

if mutex == 0 or err == ERROR_ALREADY_EXISTS
  puts "already exists"
  exit
else
  10.times do |i|
    puts i
    sleep 1
  end
end

if mutex != 0
  release_mutex.call(mutex)
  close_handle.call(mutex)
end

• CreateMutex() を呼んだ直後に、GetLastError() でエラーコードを調べて、ERROR_ALREADY_EXISTS = 183 が出ていたら既にスクリプトがどこかで起動してる。
• Mutex が確保できていたら、処理終了時に ReleaseMutex() と CloseHandle() を呼んでおく。

外部ライブラリ ffi を利用して同じことが実現できないか試してみた。ffi のインストール方法は昨日のメモを参照のこと。

_Ruby + ffi の動作確認をした

動作した環境は、Windows10 x64 21H2 + Ruby 2.6.10 p210 i386-mingw32 + ffi 1.15.5 x86-mingw32。

残念ながら、Ruby 1.8 / 1.9 (+ ffi 1.9.14)では動作しなかった。

_04_mutex_ffi.rb

require "rubygems"
require "ffi"

module WinKernel
  extend FFI::Library
  ffi_lib :kernel32
  ffi_convention :stdcall

  attach_function :CreateMutexW, [:long, :bool, :pointer], :ulong
  attach_function :ReleaseMutex, [:ulong], :bool
  attach_function :CloseHandle, [:ulong], :long
  # attach_function :GetLastError, [], :ulong
end

mutex_name = "rubyffimutexsample"
ERROR_ALREADY_EXISTS = 183

mutex = WinKernel.CreateMutexW(0, false, mutex_name.encode("UTF-16LE"))

# Add API.last_error #55 - Github Lab
# https://githublab.com/repository/issues/cosmo0920/win32-api/55
#
# GetLastError() is reset when calling Win32 API from Ruby.
# FFI::LastError.winapi_error" is a good choice.

begin
  # err = WinKernel.GetLastError
  # err = FFI::LastError.error
  err = FFI::LastError.winapi_error
rescue => e
  puts "Error : This version of ffi does not support FFI::LastError.winapi_error."
  if mutex != 0
    WinKernel.ReleaseMutex(mutex)
    WininKernel.CloseHandle(mutex)
  end
  exit
end

puts "Mutex : #{mutex}"
puts "GetLastError : #{err}"

if mutex == 0 or err == ERROR_ALREADY_EXISTS
  puts "already exists"
  exit
else
  10.times do |i|
    puts i
    sleep 1
  end
end

if mutex != 0
  WinKernel.ReleaseMutex(mutex)
  WinKernel.CloseHandle(mutex)
end

動作する状態にするまで、かなりハマった…。

問題その1。ffi を使った場合、何故か CreateMutex() が呼べなかった。指定しても「そんな関数は無い」と言われてしまう。CreateMutexA() か CreateMutexW() にしたら呼び出すことができた。ちなみに、CreateMutexW() の呼び出し方は、win32-mutex のソースを参考にさせてもらった。

_win32-mutex/mutex.rb at main - chef/win32-mutex

問題その2．kernel32.dll の GetLastError() を呼んでも、それらしい値が全く返ってこなくて悩んでしまった…。何度試しても、どんな状況でも、必ず 0 になってしまう。

そのあたり、以下のページにヒントがあった。

_Add API.last_error #55 - Github Lab

Ruby から Win32 API を呼ぶと、GetLastError() の値がリセットされてしまう場合があるそうで。そんな時のために、ffi は FFI::LastError.winapi_error というものを用意してあって、そこに GetLastError() の本来の値が格納されているらしい。

_Method: FFI::LastError.winapi_error - Documentation for ffi/ffi (master)

そんなわけで、FFI::LastError.winapi_error を使ってエラーコードを取得したら期待通りの動作になった。

ただ、Ruby 2.6 にインストールした ffi 1.15.5 には、FFI::LastError.winapi_error が用意されていたのだけど。Ruby 1.8 / 1.9 にインストールした ffi 1.9.14 にはメソッドが用意されてなくてエラーになってしまう。

昔は winapi_error ではなく win_error という名前だった、という情報にも辿り着いたのだけど。win_error に書き換えても、やはりエラーが出る。

_Rename to winapi_error - ffi/ffi@4ba55c5

どうやらどこかのバージョンの時点で win_error が追加されたけど、それは Ruby 1.8 / 1.9 でも動作してくれる ffi 1.9.14 には実装されていないようだなと…。そんなわけで、Ruby 1.8 / 1.9 + ffi 1.9.14 では、CreateMutex() を使う方法は分からなかった。

Ruby 1.9.3 限定の記述になるけれど、当時標準で添付されていた DL と fiddle を使って実現してみた。

動作確認環境は、Windows10 x64 21H2 + Ruby 1.9.3 p551 i386-mingw32。Ruby 1.8 や Ruby 2.6 では、「DL なんて無い」と言われて動かなかった。

_05_mutex_dl.rb

require "dl"
require "fiddle"

include Fiddle

libc = DL.dlopen("kernel32.dll")
create_mutex = Fiddle::Function.new(libc["CreateMutex"], [TYPE_LONG, TYPE_LONG, TYPE_VOIDP], TYPE_LONG)
release_mutex = Fiddle::Function.new(libc["ReleaseMutex"], [TYPE_LONG], TYPE_LONG)
close_handle = Fiddle::Function.new(libc["CloseHandle"], [TYPE_LONG], TYPE_LONG)
get_last_error = Fiddle::Function.new(libc["GetLastError"], [], TYPE_LONG)

mutex_name = "rubydlfiddlemutexsample"
ERROR_ALREADY_EXISTS = 183

mutex = create_mutex.call(0, 1, mutex_name)

# err = Fiddle::win32_last_error
err = get_last_error.call()

puts "Mutex : #{mutex}"
puts "GetLastError : #{err}"

if mutex == 0 or err == ERROR_ALREADY_EXISTS
  puts "already exists"
  exit
else
  10.times do |i|
    puts i
    sleep 1
  end
end

if mutex != 0
  release_mutex.call(mutex)
  close_handle.call(mutex)
end

Ruby 1.9.3 の fiddle にも、ffi と同様に、Fiddle::win32_last_error というそれらしいメソッドがあるのだけれど。何故か DL+ fiddle の組み合わせの場合は、kernel32.dll の GetLastError() を呼ぶほうが正しい値が返るようだった。

また、この場合は、CreateMutexA() や CreateMutexW() ではなく、CreateMutex() を呼んでも通る模様。

• CreateMutex の名前で呼べる場合と、CreateMutexA か CreateMutexW を呼ばないといけない場合がある。
• GetLastError() を呼んで正常動作する場合と、ffi や fiddle で別途用意されたエラーコード取得メソッドを呼ばないと正常動作しない場合がある。

とりあえず、Ruby 1.8 / 1.9 の場合は win32api を使っても警告が出なかったので、Ruby 1.8 / 1.9 なら win32api を使ってこの手の処理を書けばよさそうだなと…。

また、ffi を使えば Ruby 1.8 - 2.x でも同じ記述ができるのではと期待していたけれど、そんなことはなかった。最近の ffi じゃないと記述が通らない・正常動作しない場合もあるのだなと。そうなると、Ruby 1.8 / 1.9 で、あえて ffi を使う理由は無さそうな気がする。win32api を使ったほうが悩まなくて済む。

_二重起動の防止(1) - Advanced HSP
_CreateMutex
_API 関数解説

require "Win32API"

if ARGV.size != 1
  fn = File.basename(__FILE__)
  puts "Usage:\n    ruby #{fn} WINDOWHANDLE"
  exit
end

hwnd = ARGV[0].to_i
puts "Window Handle = #{hwnd}"

get_window_rect = Win32API.new("user32", "GetWindowRect", "lp", "i")
buf = "\0" * 256
get_window_rect.call(hwnd, buf)
x0, y0, x1, y1 = buf.unpack("l4")

w = x1 - x0
h = y1 - y0

puts "(x0, y0) = (#{x0}, #{y0})"
puts "(x1, y1) = (#{x1}, #{y1})"
puts "(w, h) = #{w}, #{h}"

ウインドウハンドルを調べる作業は、以下のツールを使わせてもらった。

_WinExplorer v1.30

Windows10 x64 21H2上で、WinExplorer 1.30 を利用できた。

あるいは、Spy++ を利用することもできそう。Visual Studio 2019 と一緒に入ってる場合もあるらしい。

_spy++を使ってクラス名を調べる方法 | 自動マクロプログラミング
_【Visual Studio 2019】Spy++の場所 - buralog

今までは vagrant-global-status というプラグインもインストールしていたのだけど、改めてググってみたら、Vagrant 本体に global-status というコマンドが追加されていて、それを使えば同じことができるらしいと知った。vagrant-global-status はメンテナンスされてないのでインストール不要らしい。とメモ。

結局、インストールしたのは以下の3つ。

vagrant plugin install vagrant-hostmanager
vagrant plugin install vagrant-share
vagrant plugin install vagrant-vbguest

> vagrant plugin list
vagrant-hostmanager (1.8.9, global)
vagrant-share (1.1.11, global)
vagrant-vbguest (0.24.0, global)

• vagrant-hostmanager : hostsファイルを書き換えるプラグイン。
• vagrant-share : HTTP共有、SSH共有等を行う。
• vagrant-vbguest : VirtualBox Guest Additionsを自動更新してくれる。

以下のページで、blenderのレンダリング実験に使えそうなデータが公開されてる。

_Demo Files - blender.org

今回は、BMW Benchmark (BMW27_2.blend.zip) を使ってみた。これは Cycles レンダラーを使うシーンデータで、CPUで計算するように設定されたシーンデータと、GPUで計算するように設定されたシーンデータ ―― 2つのシーンデータが入ってる。

以下のPCを利用して実験。

メインPC + GPU。Windows機。

• CPU : Intel Core i5-2500 (4 core / 3.3GHz / TDP 95W)
• GPU : GeForce GTX 750 Ti
• RAM : 8GB
• OS : Windows10 x64
• blender 2.79b

サブPC1。Linux機。

• CPU : AMD Athlon II X2 250 (2 core / 3GHz / TDP 65W)
• RAM : 8GB
• OS : Ubuntu Linux 16.04 LTS 64bit
• blender 2.79b

サブPC2。Linux機。

• CPU : AMD A6-3500 (3 core / 2.1GHz / TDP 65W)
• RAM : 8GB
• OS : Linux Mint 18.3 64bit
• blender 2.79b

まず、メインPCで、GPU GeForce GTX 750 Ti を使ってレンダリングしてみた。9分46秒 (586 sec)。約10分でレンダリングできた。

これを、サブPC1、Athlon II X2 250 + Linux で、CPUを使って計算、かつ、前述のページから入手したPythonスクリプトを使って、画像を100分割しながらレンダリングしてみた。1時間25分57秒 (5157秒)。つまり、PC1台で、CPUを使って計算すると、約1時間半かかる。

Linux機を2台使って、ネットワークレンダリングしてみた。43分42秒 (2622秒)。

1台では1時間半かかってたのが、2台使ったら45分になったので…。ネットワークレンダリングをすることで、1台でレンダリングするよりレンダリング時間はたしかに短くなった。しかし、期待していたほど速くはなってない…。

処理中のログが画面にずらずらと出てくるけれど、眺めていると、どうも事前の計算で時間がかかってるようにも見える。ならば、分割数を 10x10 = 100 ではなく、8x8 = 64 ぐらいにしたら、事前の計算を減らせて速くなったりしないか…。ちなみに、Pythonスクリプト内の数値を3箇所ほど弄れば、分割数は変えられる。

Linux機を2台使って、8x8 = 64分割してネットワークレンダリングしてみた。39分20秒 (2360秒)。約45分が、約40分に。ビミョーに速くなってはいるけど、それほどでもないな…。

Linux機 x 2台 + メインPC Windows機 1台、合計3台でレンダリングしてみた。かつ、分割数も 6x6 = 36分割に。計算は全てCPU。18分18秒 (1098秒)。約40分が、約20分に。

最初に1台で計算させたときは1時間半かかってたけど、3台使ったら、20分まで短縮できた。

しかし…。メインPCのGPUで計算させた場合は10分でレンダリングできるわけで…。3台のPC ―― CPUコア数で言えば、4 + 2 + 3 = 9コアを使って計算させて、20分。GPUだけで計算させたら、10分。

CPU	divide	time	time(sec)
GPU GeForce GTX 750 Ti	1	00:09:46	586
Athlon II X2 250	100	01:25:57	5157
Athlon II X2 250 + A6-3500	100	00:43:42	2622
Athlon II X2 250 + A6-3500	64	00:39:20	2360
Athlon II X2 250 + A6-3500 + Core i5-2500	36	00:18:18	1098

複数のPCを使ってCPUでレンダリングするよりも、速いGPUを買ってGPUでレンダリングしよう。そのほうが速い。

ただ、GPUを使って計算するレンダラーが使えない場合なら、複数のPCを使って分散レンダリングすることで、レンダリング時間を短縮できる可能性はありそうだなと。

とは言え、敵とプレイヤーキャラのスケール感を変えて一度考えてみる、という手はアリのような気もする。

例えば格ゲーは、自分も敵もどちらも同じぐらいのスケール感だけど、そこで差をつければ…。いや、ソレ、たぶんあのへんのタイトルになるんじゃないかな。

恋愛シミュゲーはどうだろう。ヒロインのサイズが巨大だったり、逆に極小だったり…。いや、ソレ、感情移入できるのかね。どうなのよ。

シューティングゲームではどうか。RPGではどうか。ADVゲームではどうか。「え。そこのスケール変えちゃうの？」的部分がどこかに無いか…。

もしや、DXRuby(RubyからDirectXを呼び出せるライブラリ)も遅くなってたりして。と思ったけど、自分が書いたスクリプトをいくつか動かした範囲では、DXRubyは大丈夫だったみたい。助かった。

他にも色々動作確認してみたけど。

• DXRuby : OK
• STREET FIGHTER IV BENCHMARK : OK
• 3Dカスタム少女 : OK
• カスタムメイド3D : OK
• いたずらシリーズ(いたずら極悪、イチャずら) : OK
• レイプレイ : NG

どうやら手持ちのアレコレの中では、Illusion製の3Dゲームだけがダメっぽい…。古い3Dゲームの類が全滅ならまだ分かるけど、何故に…。

「そんなアレなソフトで不具合出たぐらいで」と言われるかもしれんけど、もちろん自分はたまたまコレぐらいしかアプリを持ってないからこの程度の結果で済んでるわけで、他にも色んな3Dゲームを持ってる人なら「コレもダメだった」「コイツもダメだった」と次々に不具合と遭遇するのではないかと心配するわけで。なので「そんなソフトぐらいで」とは言えない部分があるでしょうと。ゴキブリを1匹見かけたら、みたいな感じで。

いや待て。そもそもコレは本当に Windows10 Anniversary Update の不具合なのだろうか。実は Windows7 から Windows10 にアップグレードした際に症状が出ていたけど自分が気づかなかっただけ、ということはないか。

不安になってきたので、ココは一つ前のビルドに戻して確認せねばという気分に。てなわけで、ビルドを戻してみたり。

以前のビルドへの戻し方は、スタートボタン → 設定 → 更新とセキュリティ → 回復 → 以前のビルドに戻す、だったかな…。1時間もかからずに、バージョン 1511、ビルド 10586.545 に戻ってくれた模様。

それにしても…猶予期間が10日間しかないってのは…酷い…。

なんでも、ユーザのデータを取ってみたら大体10日以内に戻してたから、というのが改悪の理由らしいけど。ソレ絶対「Windows10への無料アップグレード期間内に一旦Windows10にしてすぐに古いOSに戻せばアップグレードできる権利だけは貰えるから」てな理由で戻した人が多数混じってないかと思うわけで。取得したデータの見方・捉え方が間違ってないか…。

バージョン 1511上で動作確認してみたけど、Illusion製のゲームもヌルヌルと動いてくれた。やっぱりそうだよな…。記憶違いじゃなかった。

ということで、Windows10 Anniversary Update を入れると昔作られた3Dゲームがプレイ不可能なぐらいに遅くなる、という不具合に遭遇する可能性があるよ、と言えるのかもしれないなと。

このあたりの情報をググってみたけど、おそらくは「ふたば掲示板」っぽいページで、チラリと言及が。「一部の古いソフトが遅くなるのはコアクロック数が全く上がらないバグっぽい」という説があるようで。

一応、ビルドを戻す前にその情報を見かけたので、電源設定で「高パフォーマンス」設定にして、CPUクロックを落とさない状態にしてから動作確認してみたのだけど、残念ながら変化が無く。この場合のクロックって、GPU側の話なのかな…。

英語圏の掲示板では、3Dゲームのフレームレートが落ちる問題に対して「Game DVRを無効にしたら改善した」という事例もあるようだなと…。Anniversary Update をしたことでそのあたりの設定が初期化された可能性もあるのだろうか…。でも、自分の環境では、バージョン1511でもそのへんの設定を弄った記憶がないのだけど…。

「CGを使ってるんだぜ！ どや！」と宣伝してた、 _アニメ映画版レンズマン は、ちょうど1984年の作品。あの頃のCGなんて、 _あんなレベル だよなと…。それでいて手間はめちゃくちゃかかってて…。

_JCGL 制作部の伝説(198X年) - 1980年からプログラマしています で興味深い話が。

　NYITのレンダリング・アルゴリズムは、Zバッファだった。今では当たり前のテクスチャ・マッピングすらなかった。Zバッファでは、アルゴリズムの都合上、透明体の表現ができない。レンズマンの映像ディレクター大口孝之氏は、オプチカル・プリンターで、20枚ものCG画像をコンポジットをして、レンズマンのオープニング・シーケンスを作り出した。

JCGL 制作部の伝説(198X年) - 1980年からプログラマしています より

今なら合成作業と言えば当然CGで、だろうけど。当時はどうやら「CGで合成？ 何言ってんの」状態で、レンダリング結果を _オプチカル・プリンター で合成するのが当たり前、かつ、レンダリングアルゴリズムの欠点すらソレで補っていたと…。コンピュータの計算で光らせてるんじゃなくて、フィルム撮影技術、アナログ技術を駆使してCGを光らせてたと…。頓智の世界…。

_ピクサー の設立が1986年。

なのだけど、ピクサーは元々ILMのCG部門だったはずで…。ILMが手掛けてた、 _スタートレックII カーンの逆襲 が1982年。 _ヤング・シャーロック/ピラミッドの謎 は1985年。ヤング・シャーロックでは、ステンドグラスから出てくるアレをCGで作ってて、当時話題になったような…。

_GTC - ルーカス・フィルム、映画制作の在り方を変えたGPUのパワーについて講演 (1) 模型ベースの特撮からCGへ | マイナビニュース で少し紹介されてた。記憶は合ってたらしい。

「アビス」が1989年、「ターミネーター2」が1991年か…。たった数年で、結構レベルが上がってるなあ。もちろん今見るとアレだけど。

今はもう、個人でもPC使ってCG映像を作り放題だけど。1984年前後の状況は…。

_MZ-700 が1982年の発売だったらしい。 _野球拳がこんな感じの画面になる PCで。もちろんこんなPCで、CG映像なんか作れるわけがない。

_Macintosh が1984年の発売。あの頃は白黒画面だったっけ。

_パソコンの歴史　１９８４年 というページにまとまってた。画面はえてして8色〜16色しか出せない時代、なのですな…。

そういや当時のコンピュータ関係の本で、「コンピュータでアニメーションを作ろう！」→「まずは、8ミリフィルムカメラをコンピュータから制御する回路を作ります」→「コレで1コマずつ画面を撮影できるよね？」→「アニメーションが作れますね！」という内容を読んだ記憶も。

考えてみたら、当時のPCスペックでは、24コマ/秒で静止画を次々に表示するところからして無理だったなと。記録媒体もカセットテープだったし…。どこから画像データ読み込んでくるんだよ、みたいな。カセットテープからの読み込みは、600ボーとか1200ボーとかそんな速度だから…1秒間に1200bit = 150Byte、24コマ/秒なら1コマ50bit = 6.25Byteですよ。1コマ、英数字6文字分の情報量で、一体どんな絵が出せるのかと。そりゃ「1コマ出来たらフィルムで撮影して残しておこうぜ！」って話になりますわ。

そんな調子だから、当時、映画用のCGカットを作るなんて、めちゃくちゃ金がかかったんだろうなと…。

でも、 _パソコンの歴史　１９８６年 によると、X68K が 1987年の発売だったらしい。たった数年で32768色(65536色？)が出せるPCが買えるようになったのか…。X68Kが登場すると、DoGAの話も出てくるから、個人でもどうにかCG映像を作れる、という話にもなってくるのかしら。

その前に _Amiga があったか…。1985年に発売されたらしい。 _LightWave 3D がいつから存在してたのかはググっても分からなかったけど、VideoToaster なる動画編集用ハードウェアがあったぐらいだから、もうその頃はPCで動画編集する未来がフツーに見えてたんだろうなと。

そういえば、十数年前とは内装が違ってたような…。改装したのかな…。と思ったけど、前と変わってないのかな…。N歯科の内装と記憶が混ざってる気もしてきた…。

Iデンタルクリニックもそうだったけど、待合室に歯の治療関係の本が一冊も無かったのが微妙に気になる…。なんだか、待合室にその手の本を山ほど置いてある歯医者さんと、一切置いてない歯医者さんが居るよなと。あの違いはどこから来るんだろう。そこで歯医者さんの傾向を判別できたりするのかしらん。

まあ、今時は予約を入れるのが当たり前になってるから、本来なら患者さんが待合室でその手の本を読んでる時間も無いはずだから本は要らないはず、という判断だってできたりもするのかな。

オーディオコメンタリーで監督さんが言及していて、巻き戻してみて「うわ、マジだ！」と驚愕しましたが。ノートに鉛筆でスケッチをしてるカットで、ノートの紙が鉛筆で押されて凹むのですよ。…文章で説明しても何言ってんのか分かんないと思うけど、見れば分かる。気付いた瞬間、ゲロ吐きそうに。アニメでそこまでやるか…！ ある種、これは狂ってるなと。

監督自身、「ここまでやる意味あるのかなあ…」と弱音(?)を吐いてましたけど。意味はあったんじゃないかなと。だって、ノートに鉛筆でスケッチをしてるだけなのに、そのカットだけ見ても、「綺麗だなあ…」とこっちは感じたわけで。それってつまり、抽象化された映像に、無意識なレベルで現実性を連想させる動きを付加したことで、結果、見る人の脳内に、その人にとっての理想的な映像を結実させることができました、ってことですから…。しかし、やっぱり、この監督さん、ちょっと狂ってる…。＜褒めてます。

個人的に、見ていて嬉しかった点が。監督さんが、曲が持つ力、歌が持つ力をしっかりと信じていて、それを最大限、自作品の中で活用したいと考えてることが伝わってきたあたり、なんだか嬉しくなったというか。

初見時、大江千里作詞作曲、秦基博がカバーした「Rein」が流れてきた瞬間に、「…ズルイ！」と思ってしまいました。や、「ズルイ」云々は冗談ですけど。これぐらい曲を活用してこそ映画・映像作品と呼べるのではないかなあ、と思ったわけで。…大江千里の曲、いいですよねえ。

邦画においては、本編がそれなりに頑張ってるのに、途中や最後で頓珍漢な歌を突っ込む時が稀にあるわけで。そういうのを見るたびに、海原雄山ノリで「この曲を選んだのは誰だー！」と怒鳴りたくなるわけですよ。 *1

映画は、総合芸術ですよ。写真、絵画、演劇、あらゆる要素を総動員して、観客に何かを伝えるべくジタバタしてこそ映画ってもんで。なのに、どうして、音楽だけ村八分にしちゃうのか。そこは、「音楽の持つその力…我に差し出せ！」ぐらいの姿勢で取り組まないと。映画が総合芸術であると理解できてないから、迂闊に音楽を軽視できるんですよ。映画をなめたまま作ってんじゃねえよと。

音楽が映像をブーストして、映像が音楽をブーストするぐらいの関係じゃないといかんだろうと。その音楽を聴いたら映像が脳裏に浮かび、映像を見たら音楽が頭の中で流れ始める…。本来、そのくらいの良好な関係を目指さないといかんのではないですかと。

その点、新海作品は、総合芸術を作ろうと立派にジタバタしてる印象があるのでした。とは言え、姿勢はともかく当たり外れはありますが…。少なくとも、「秒速」と「言の葉」は、歌の力を上手く使えてる気が。「このタイミングでコレを流すか…。いやー、ズルイわあ。そりゃ絶対イイ感じになるわあ」と自分は思えてしまったあたり、使い方に関して見事成功した証拠、じゃないのかなと。

この作品、キャラの塗り分けを一工夫して、照り返しやトレス線の色に環境光を反映したそうで。その試みは、上手くいっていたような気がしたり。そういうやり方があったか、頭いいなあ、たしかにパッと見の印象がかなり違う、なるほどなあ、と。

まあ、考えてみたら、例えば3DCGにおいては環境光を意識するのはごく当たり前のことだし、イラスト業界でもそういうテクニックがそこそこ普及してるのだから、それをセル塗りに応用するのは全然アリな発想だよなと。というか、「となりのトトロ」でも、トレス線の色を一工夫、なんてことをやってたわけだから、ここまでやった作品は滅多にないとしても、着眼点としては何十年も前から皆が目にしていたわけで。でも、よくまあそこらへんを意識して、手間をかけたものだなあ、と感心するわけですけど。

そのあたり、宮崎駿監督が、昔、新人向けに書いたという研修資料(?)を思い出すのです。「どんな風景もしっかり観察すれば、セルと塗り分けで必ず表現できるはず。そういう気概を持って仕事に取り組め！」みたいな熱い主張が書いてあった、ような記憶が。手元にその本残ってないのでうろ覚えですけど。

でも、フツー、よほど意識の高いアニメーターさんでもない限り、そこまではやらんわけですよ。しかも、宮崎駿監督のそのノリって、どちらかというと東映動画のノリで。虫プロのスタイリッシュな画作りが席巻・普及してしまった現代においては、本当は王道なんだけどマイナーな扱いを受けてる考え方ではないかとも思えたり。

しかし、今回、新海監督とそのスタッフは、その教えを、ある種愚直さすら感じるほどに、真摯にどこまでも徹底的に守って取り組んで、見事に成功させたわけで…。

テレコムやジブリで育ったわけでもなければ、宮崎駿監督がどちらかといえば嫌っている、デジタル技術に頼った画作りをしている…。そんな新海監督が、実は宮崎駿監督の教えを最もキッチリ守ってるように見えてしまったあたり、これはなんだか面白い状態だなと。もしかすると、画作りの方向性に関しては、新海監督が宮崎駿監督の一番の後継者じゃないの？ とすら。…まあ、テレコムやジブリで育った方から、「何言ってんだよ、俺達だってちゃんと守ってるよ？ 目ん玉ひんむいて俺達の作品しっかり見てみろよ」と怒られそうではありますけど。 *2

もちろん、やり方・考え方はそうだとしても、脚本やコンテレベルの作風は全然違うわけで。新海監督の作風は、ジブリに呼んで作らせてみたものの、完成映像を見て宮崎駿監督が激怒したと噂される、望月智充監督の作風に近い印象が。なので、あくまで、画作りの姿勢は、という話でしかないですが。

アニメ様が、「新海監督作品は最先端アニメ」と喩えてるけど。デジタルという最先端を使いながら、ある種絶滅危惧種に近い、東映動画の画作りの思想を復権しつつあるという点で、そこにはハイブリッド性がありそうだなと。そういう面でも、コレは最先端アニメ、なのかもしれないなあ、と。

このあたり、もしかすると、アニメーター出身ではなく、撮影出身の監督さんだからそういう純潔？を守れているのかしら、と邪推もしたり。

アニメーターだったら、テレコムやジブリに入ろうと努力したり、宮崎駿から直接指導を受けたりして、しかし、「ここまではやれん…」と挫折しそうだよなと。しかも、大塚康生さんあたりがこっそりと、「宮さんはあんなこと言ってるけどさ。フツーそこまでできないから。アレは宮さんが特別だからできることですよ」みたいな優しい言葉を耳打ちしちゃったりして、「理想としてはそうだけど、なかなかできることではないのだ」と若干日和ってしまう可能性も。って全く根拠のない勝手な妄想ですが。実は大塚康生さんのほうがもっと厳しかったりして。

何にせよ、新海監督のソレは、「アニメーターではなかったから」「撮影・仕上げという職種の作業内容を熟知してるから」、そして、「デジタルの利便性を知っているから」こそ、「ここは撮影時にこうすればできるかも…」と発想が湧いて、それ故にかろうじて成立している、そんな可能性もあったりするのかなあ、と想像してみたりもして。実際はどうなのか全然分かりませんけど。

このあたり、ピクサーの各監督さんにも似たような何かを感じるのですよね…。ピクサーの監督さんが来日して、インタビューを受ける際に、「自分達は宮崎アニメから、緩急・コントラストの重要性を学んだ」とか言ってるわけですけど。 *3 その、宮崎駿の弟子達が集って作ってるはずの近年のジブリ作品が、緩急を活かせてるかというと…これがちょっと微妙なわけで。そもそも近年の宮崎アニメ自体がそのへん微妙。

新海監督にしろ、ピクサーにしろ、バリッバリにCGを駆使してる監督さん・スタジオですが。しかし、考え方に関しては、宮崎駿監督のソレをしっかり守ってる・取り込めている。そこがなんだか面白いなと。もしかすると、別の職種であったり、外部のスタジオのほうが、そこにあった本質・重要性を意識しやすいのかな？ てなことをチラリと思ったりもするのでした。…実際どうかは分かんないですけど。

これだけ長々と書いてしまうということは…。自分、よほど、この作品が気に入ったんだなあ…。

面白いとは思わなかったらしい。幼児のハイテンションぶりが鼻について今一つだったとかで。…てっきり、トラブルに巻き込まれた三姉妹に感情移入してしまったのではないかと予想したのだけど、そういうわけでもないらしく。単に、「語尾に『！』をつけて喋るキャラが大嫌い」との話で。なかなか難しい。

側版をつけようとして四苦八苦。ビクともしない。うーむ。

アロシステム販売 *1 、 _スカイテック製造 の、SKII-200SWという型番のケースなのだけど。片方の側版の、本体に引っ掛かる部分が、数mmずれてるような。…工場の人は、まるで中国の自動車工場よろしく、トンカチでガンガン叩いて側板をつけて出荷したに違いない。

でもまあ安いから。

今のラインナップは、前後に12cmファンがついてる _SKII-201 なる型番らしく。やはり前面のプラスチックで吸入口を塞いだのがアレだったのか…。でも、 _SKII-180 とやらと中身はそっくりなのだけど。電源ボタンの形が違うだけ。

添付のケーブルの先が、ジャンパー端子に挿すような端子なわけで。M/B上にその手の端子が無いと使えないのだろうな。

/var/log/Xorg.0.log から。

(--) MGA(0): Linear framebuffer at 0xE3000000

size は 0x800000 かしら。

lspci の出力結果。 _Xの描画を速くする というページを参考に。

# /sbin/lspci -v
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 02)
        Flags: bus master, medium devsel, latency 64
        Memory at e4000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: e1800000-e2dfffff
        Prefetchable memory behind bridge: e2f00000-e3ffffff

00:04.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
        Flags: bus master, medium devsel, latency 0

00:04.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 32
        I/O ports at d800 [size=16]

00:04.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
        Flags: bus master, medium devsel, latency 32, IRQ 3
        I/O ports at d400 [size=32]

00:04.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
        Flags: medium devsel, IRQ 9

00:06.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891
        Subsystem: Adaptec 2940U2W SCSI Controller
        Flags: bus master, medium devsel, latency 32, IRQ 3
        BIST result: 00
        I/O ports at d000 [disabled] [size=256]
        Memory at e1000000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [dc] Power Management version 1

00:0a.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 02)
        Subsystem: Melco Inc: Unknown device 030e
        Flags: bus master, medium devsel, latency 32, IRQ 4
        I/O ports at b800 [size=256]
        Memory at e0800000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [40] Power Management version 7

00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
        Subsystem: Unknown device 4942:4c4c
        Flags: bus master, slow devsel, latency 32, IRQ 10
        I/O ports at b400 [size=64]

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G200 AGP
        Flags: bus master, medium devsel, latency 64, IRQ 11
        Memory at e3000000 (32-bit, prefetchable) [size=16M]
        Memory at e2000000 (32-bit, non-prefetchable) [size=16K]
        Memory at e1800000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at e2ff0000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 1
        Capabilities: [f0] AGP version 1.0

_ITmedia エンタープライズ : Linux Tips「MTRR機能を使ってXの描画を高速化させたい」
_X Window System の描画速度を改善する - MTRR の設定で、4倍程度にまで改善されます。
_X Window Systemの描画速度を改善する

上記ページを参考にして作業。どうせなら速いほうがいいし。

mtrr が使えるかどうか確認。

# cat /proc/cpuinfo

mtrr の文字が見えた。使えそう。

/proc/mtrr が存在するかどうか確認。

# ls /proc/mtrr

設定を書き込む。ビデオカードによって値は違う。

# echo "base=0xe3000000 size=0x800000 type=write-combining" > /proc/mtrr

/etc/lilo.conf に、

append="acpi=off resume2=swap:/dev/hda2 panic=10 video=vesa:ypan"
vga=794

こんな感じの記述を追加して、

# /sbin/lilo

でMBRに書き込み。

append="video:xxxx" は、バックスクロール用の設定らしい。append="video=vesa:ypan" と append="video=vesa:ywrap" の2つがあるのだとか。ypan は遅いけど互換性が高く、ywrap は速いけど動作が怪しい。らしい。

vga=794 は、1280x1024 16bit の指定。個人的に、1280x1024 は縦横比が他の画面モードと違うから好きじゃないんだけど。1400x1050 が指定できればなぁ…。

mtrr云々を、毎回起動時に設定するようにした。/etc/rc.d/rc.local の最後のあたりに、

if [ -f /proc/mtrr ]; then
    echo "base=0xe3000000 size=0x800000 type=write-combining" >| /proc/mtrr
fi

を追加。

なんだか1400x1050 があるようにも見える。引用。

    # VESA mode crossreference (in hex):
    # Bits  640x480 800x600 1024x768 1280x1024 1600x1200 1400x1050
    # 8     101     103     105         107     11c
    # 15    110     113     116         119     11d
    # 16    111     114     117         11a     11e       142
    # 24    112     115     118         11b     11f       143
vga = 0x343
    # vga = normal, or 0x200+VESA mode number
    # Make sure you compiled VESA framebuffer into the kernel!
    # Kernel stanzas can have 'append = "video=vesa:ypan"' but
    # this appears to be broken at the moment.

上の表に、0x200 を加算したものを指定しろ、と書いてある？

試しに、0x343 = 835 を指定してみた。

ダメだった。やっぱり無いんだな。

_＠IT：コンソールを高解像度で表示するには（LILO編） を参考に、vga=791 と vga=775 を指定。

771     800x600     256色
773     1024x768    256色
775     1280x1024   256色

788     800x600     6万5000色
791     1024x768    6万5000色
794     1280x1024   6万5000色

789     800x600     1600万色
792     1024x768    1600万色
795     1280x1024   1600万色

該当部分だけ、/etc/lilo.conf から削除してみた。…スクロールが速くなった。

結局のところ、mtrr 関連を /etc/rc.d/rc.local に書き込んだだけ、という話になってしまった。

ln -s /home/bkup/old /old

みたいな。作業をしやすくするために。

_Vine Linux のインストールと設定 - NTPD の設定

今まではこんな感じの ntp.conf だった。

server ntp1.plala.or.jp
server ntp2.plala.or.jp
server ntp1.jst.mfeed.ad.jp
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp

#server clock.nc.fukuoka-u.ac.jp
#server clock.tl.fukuoka-u.ac.jp

restrict default noquery notrust nomodify
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0

# fudge 127.127.1.0 stratum 3
# server 127.127.1.0

driftfile /etc/ntp.drift
logfile /var/log/ntp.log

_昔のメモ を参考にしつつ作業。

_NTP,時刻同期サーバー設定方法 というページに、restrict の意味が書いてあった。アクセス制御だったのか…。

結局、/etc/ntp.conf はこんな感じに。

#restrict default noquery notrust nomodify
#restrict 127.0.0.1
#restrict 192.168.1.0 mask 255.255.255.0

server ntp1.plala.or.jp
server ntp2.plala.or.jp
server ntp1.jst.mfeed.ad.jp
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp

# server clock.nc.fukuoka-u.ac.jp
# server clock.tl.fukuoka-u.ac.jp

server 127.127.1.0
fudge  127.127.1.0 stratum 10

driftfile /etc/ntp.drift
logfile /var/log/ntp.log

restrict を指定すると ntpq -p の結果がなんだか変で…。

/etc/rc.d/init/httpd stop

で止めてから。emacs で昔の httpd.conf と現在の httpd.conf を開いて、M-x compare-window で比較しながら修正。

mod_gzip の設定で悩む。 _2003/05/12の日記 や、 _ITmedia : Linux Tips「Apacheにmod_gzipを組み込んで帯域を節約したい」 を参考にしながら作業。

httpd.conf の一番下に、/etc/httpd/conf.d/*.conf を include するような設定があった。もしかしてそちらに書いておけば、一々毎回 httpd.conf を修正しなくても済むのかしら。

mgstat もインストール。 _2004/05/25の日記 を参考にしつつ。…む。./configure を実行したら、GDライブラリが無いと言われた。apt-get で perl-GD、gd-devel、libpng-devel を入れてみた。… libpng-devel が関係してたみたい。

相変わらず DisplayLogin と DisplayQuit の設定に関する動作が怪しい。特に DisplayQuit。表示されない場面が多いような。

とりあえず、anonymous でログインできないところまでは確認。…「パスワードが間違ってる」と言われ続けるあたりがちょっとアレだけど。

Vine 3.0 から標準で入らなくなった samba。なんだか色々と設定項目が変わってる。まず、設定ファイルの場所が違うし。/etc/samba/ 以下になったのだな。

SWAT もインストール。一応動いてるようには見える。/etc/hosts.deny に、

swat: all

を追加した後、/etc/hots.allow に、

swat: 127.0.0.1 192.168.1.12 192.168.1.16

といった感じで、利用できるPCのIPを追加。

_Winbind というのがちょっと気になる。便利なサービスらしいのだけど…何が便利なのかよく判ってない。WinNTでネットワークを構築してる人にとっては嬉しいのかしら。

smbclient の動作がなんだか変。WinXP 機に接続すらできない。

timeout connecting to 192.168.x.xx:445

といった表示になる。もしかして WinXP のファイアウォール設定が絡んでるのかしら。それとも自分、何か使い方を間違えてるのだろうか。

_LILOで複数のカーネルから1つを選択して起動するには

上記ページに、

initrd=/boot/initrd-2.4.3-12.img　←SCSIを使用しない場合は不要

とあったので、/etc/lilo.conf 中の該当行を「#」をつけてコメントアウトしてみた。…SCSI関連の初期化がされなくなって起動が速くなった。

たしかにコンソールの仮想画面はあまり使ったことがない…。参考にさせてもらって、自分も無効に。/etc/inittab 中の該当部分をコメントアウト。かつ、一部追加。

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1 --noclear
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
# 4:2345:respawn:/sbin/mingetty tty4
# 5:2345:respawn:/sbin/mingetty tty5
# 6:2345:respawn:/sbin/mingetty tty6

_ITmedia : Linux Tips「余計なディスク書き込みを軽減させよう〜noatime編〜」

/etc/fstab のあちこちに、「noatime」を追加。

# apt-get update
# apt-get install postfix dracd db4 db4-devel db4-utils pam-devel gdbm-devel

# /etc/init.d/portmap start
# chkconfig portmap on

# cat /etc/mail/dracd.allow

# vi /usr/sbin/rc.dracd

/usr/sbin/rpc.dracd -e 3 &

# /etc/init.d/dracd start
# chkconfig dracd on

Vine の FTPサイトから SRPM を取得して再構築する方向で作業。 _「8.4. ソースパッケージからバイナリパッケージを再構築(rebuild)する。」 を参考に。下準備として、root で build-essential をインストール。

# apt-get install build-essential

…既に最新版が入ってた。後は一般ユーザになって作業。

なのだけど。「一般ユーザのホームディレクトリにある ~/rpm/ を使え」とマニュアルには書いてあるものの。どこに *.src.rpm を入れたらいいのかわからん…。

_Vine Linux 3.1で電源が切れない場合の対処 というページに情報があった。~/rpm/SRPMS/ に保存するらしい。

$ cd ~/rpm/SRPMS/
$ apt-get source qpopper

qpopperのSRPMをインストール。

$ su
# rpm -ivh qpopper-x.x.x-0vlx.src.rpm

SPECファイルを修正する。…これは一般ユーザで作業しちゃっていいのだろうか。ちと怪しいけど。

$ cd ~/rpm/SPECS/
$ vi qpopper.spec

で、肝心の、qpopper.spec の修正箇所は…なんだか色々なパターンがあるらしく。

(%buildセクションに追加)
--prefix=/usr \
--enable-bulletins=/var/spool/mail/bulletins \
--enable-specialauth \
--with-pam=qpopper \
--with-popuid=pop \
--enable-apop=/etc/pop.auth \
--enable-drac

(%preセクションのuseraddにオプションを追加)
/usr/sbin/useradd -M -g pop pop -c "Pop Account" -d /dev/null -s /dev/false

 (%buildセクションに追加)
--prefix=/usr \
--enable-bulletins=/var/spool/mail/bulletins \
--enable-specialauth \
--with-pam=qpopper \
--with-popuid=pop \
--enable-apop=/etc/pop.auth \
--enable-drac    (←これ)

(%preセクションのuseraddにオプションを追加)
/usr/sbin/useradd -M -g pop pop -c "Pop Account" -d /dev/null -s /dev/null

$ ./configure \
--prefix=/usr \
--mandir=/usr/share/man \
--enable-bulletins=/var/spool/mail/bulletins \
--with-popuid=pop \
--enable-drac
$ make

$ su
# /usr/sbin/groupadd -g 110 pop
# /usr/sbin/useradd -c "Pop Account" -u 110 -g 110 -s /bin/false -r -d /var/spool/mail pop

$ ./configure \
--prefix=/usr \
--mandir=/usr/share/man \
--enable-bulletins=/var/spool/mail/bulletins \
--enable-specialauth \
--with-pam=qpopper \
--with-popuid=pop \
--enable-apop=/etc/pop.auth \
--enable-drac
$ make

$ su
# /usr/sbin/groupadd -g 110 pop
# /usr/sbin/useradd -c "Pop Account" -u 110 -g 110 -s /bin/false -r -d /var/spool/mail pop

要するに…

%buildセクションに
--enable-drac
を追加。(前の行の最後に \ をつけること)

…して。

-c "Pop Account"

ユーザコメントを、"Pop Account" に。

-u 110

user ID を 110 に。

-g 110

group ID を 110 に。

-s /bin/false

shell を /bin/false に。

-r

システムアカウントで。

-d /var/spool/mail

ホームディレクトリを /var/spool/mail に。

pop

pop という名前のユーザを。

作成する、という感じなのかしら。ただ、-M オプションがわからんけど。

とりあえず、あらかじめ group を作成してみたり。

# /usr/sbin/groupadd -g 110 pop

で、SPECファイルの %pre セクションは下のような感じに。

%pre
# Add the "pop" user
/usr/sbin/useradd -c "Pop Account" -u 110 -g 110 \
    -s /bin/false -r -d /var/spool/mail pop 2> /dev/null || :
exit 0

こんな感じでどうだらう。

RPM作成。

$ rpm -ba qpopper.spec
$ cd ~/rpm/RPMS/i386/

qpopperをupdate。

# su
# rpm -Uvh qpopper-x.x.x-0vlxdrac.i386.rpm 

で、いいのかしら？

pam設定ってのがよくわからないけど。

inetd設定。以下のファイルに以下を追加、というかコメントアウトを外す。

# vi /etc/inetd.conf

pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd  in.qpopper

以下のファイルに以下を追加。

# vi /etc/hosts.allow

in.qpopper: all

inetデーモン再起動。

# /etc/init.d/inet restart

pamの設定。

# vi /etc/pam.d/qpopper

#%PAM-1.0
auth       required     /lib/security/pam_pwdb.so shadow
account    required     /lib/security/pam_pwdb.so

既に書いてあった。

ちょっとよくわからないのが、

mydestination = $myhostname, localhost.$mydomain $mydomain

という記述。「,」は要らんのだろうか。それと、

mynetworks = 192.168.1.0/24, 127.0.0.0/8 check_client_access btree:/etc/mail/dracd

という記述はOKなのだろうか。 _Postfix on TurboLinux 8 - Planet Works というページに似たような記述があったから大丈夫かしら。

Win上からサーバへPOP認証後、サーバ側で次のように打って確認。

# db_dump -p /etc/mail/dracd.db

下のような表示になればOK。

VERSION=3
format=print
type=btree
HEADER=END
192.168.1.26 ← クライアントのIP
1097475530 ← 色々変わる
DATA=END

5分後、再度確認。

# db_dump -p /etc/mail/dracd.db

IPが消えてればOK。

IPが消えてる状態でいきなりメール送信しようとしても拒否される、はず。

って、送ることができてしまった。ダメじゃん。どうやら、

mynetworks = 192.168.1.0/24, 127.0.0.0/8 check_client_access btree:/etc/mail/dracd

がマズイらしい。

mynetworks = 127.0.0.0/8 check_client_access btree:/etc/mail/dracd

なら、なんとか。つまり前者は 192.168.1.x から送られると問答無用で送れてしまうということかしら。

# postfix check

で、設定ミスが判るらしい。

/etc/postfix/main.cf の

unknown_local_recipient_reject_code = 450

を 550 にしておく、らしい。

_ただのにっき(2002-08-26) - screen
_おぼえがき - tips for GNU screen

自分も真似させてもらったり。

escape ^Tt
vbell on
vbell_msg "   Wuff  ----  Wuff!!  "
hardstatus alwayslastline "%w"
defscrollback 8192
defflow off

標準の C-a は行の先頭に飛ぶとき頻繁に使うので、C-t に割り当て。

vbell_msg が有効になってないのが不思議。画面全体がフラッシュする。hardstatus を使ってるからだろうか。「Wuff ---- Wuff!!」のメッセージが見たいのだけど…。

_起動時のコンソールのキー配列を変更するには
_linux-keyassign-pseudoHOWTO

解凍して書き換えないとダメか…。

# cd ~

# mkdir tmp
# cd tmp
# cp /usr/lib/kbd/keymaps/i386/qwerty/jp106_Ctrl_CAPS.kmap.gz .
# gzip -d jp106_Ctrl_CAPS.kmap.gz

cat jp106_Ctrl_CAPS.kmap してみたら、中身はこんな感じだった。

# jp106_Ctrl_CAPS.kmap

include "jp106.kmap"

keycode  29 = Caps_Lock
keycode  58 = Control

# EOF

Caps_Lock を設定してるところをコメントアウト。

# keycode  29 = Caps_Lock

リネームして圧縮。キーマップが色々入ってるところにコピー。

# mv jp106_Ctrl_CAPS.kmap jp106_NOCAPS.kmap
# cp jp106_NOCAPS.kmap.gz /usr/lib/kbd/keymaps/i386/qwerty/

キーボード設定を変更。

# kbdconfig

「jp106_NOCAPS」がリストの中に見える。変更してみた。上手くいったように見える。

こういうの作ってたら楽しいだろうなー。

そういや先日、女性らしき方から質問メールが着て、真面目に返信しちゃったけど。アレもspamだったのだろうか。なんだか不安になってきた… (;´Д｀) *1

で、いいんだよなぁ…とりあえず…

読みまするよ。

読むのであります。

こういう客層に受けてる人だったのか。興味なかったんで全然知らなかった。

同じパーツ構成・デザインの車があるようだし。自分で独自に改造したなら、立体的には、個性溢れるデザインになりそうな。でも、そうはなってない。ということは、メーカからこういう車が売ってるか、オプションパーツが販売されてるか、もしくは同じような形に改造してくれるサービスがある、ということなのかな。

CRTとデータレコーダとキーボードが一つになったデザイン。いいなぁ。K2Eとか1200も好き。なにかこう、憧れがある。ちょうどその頃、「マイコン、 *1 欲しいなぁ。欲しいなぁ」と涎を垂らしながら広告を眺めてたからなのですが。

PC-8001、6001、8801は、街の電器屋さんで触れていたから、それほど魅力的でもなかった。MZシリーズは、当時の須賀川市では影も形もなかったので、そちらのほうが気になる存在でした。 *2

こちらの記事も、非常に興味深い。敗戦により、仮に日本が、東日本・西日本に分割された場合。その後、語学(?)的には、どのように変化していくかという考察。なるほどなぁ。こういう、「if」の話は、面白いであります。