基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
気閘 ： きこう
安穏 ： あんおん、あんのん
通函 ： かよいばこ、つうかん
終章またまた急いでまとめた感じが。
楽天的なエンディング。 この結末は無理がありすぎる気がする。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
辞書化した文節区切り情報を利用する機能の パラメータチューニングが悪いらしく、 たとえば「ごごからはきゅうなあめにちゅうい」とか変換すると 滅茶苦茶な文節区切りを提示してくる。
そもそもこの機能を無効にしたい方は、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-1
にて無効化できます。
また、本機能の効き目を無効にはしないけれど
弱めに調整したい場合は、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 3.0e-5
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 7.6e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 3.6e-8
とかして下さい。
値を小さくすればするほど、本機能の効き目が弱くなります。
一部の界隈で騒がれている（らしい） 統計的かな漢字変換のＮグラム方式が、そんなに良いのか、 と気になったので、読み仮名ベース文字 変則２グラムを実装してみた。 単語２グラムとか文節２グラムとかじゃない辺り日和ってる。 本来のＮグラムの漢字表記のデータが付いておらず 読み仮名のみの変則であるのは、 Anthy の構造上、文節区切り判定の際に表記の一致判定を行うと、 使い物にならないくらい処理が遅くなる為。
${HOME}/.anthy/conf に
#
YOMICHAR2GRAM_MODE true
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-5
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-8
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSUDIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_UCDIC 0.0e-1
#MBR_MODE_LATTICE_BIASPROB_BY_OCHAIRE 6.6e-1
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2KY 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2T 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2D 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_PRE_CORE 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_CORE_POST 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_PRE_CORE 0.0e-12
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_CORE_POST 0.0e-12
LATTICE_BIASSCORE_BY_COMPOUND 0.0
LATTICE_BIASSCORE_BY_CORPUSUDIC 0.0
LATTICE_BIASSCORE_BY_UCDIC 0.0
#LATTICE_BIASSCORE_BY_OCHAIRE 1000.0
#LATTICE_BIASSCORE_BY_LEARNEDFREQ 10.0
#LATTICE_BIASSCORE_BY_DEPHISTORY 5.0
#
を追加すると、
読み仮名ベース文字 変則２グラムモードで文節区切りを行ないます。
数分試してみましたが、結構無難な候補が出るのね……。 ちょくちょく変な文節区切りも出てくるけれど。 読み仮名ベース文字 変則２グラムで ここまでまともな変換結果が出るとは思わなかった。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
今回追加した 辞書化した文節区切り情報を利用する機能の パラメータチューニングがまだ悪いらしく、 調整してみた。
そもそも今回の機能を無効にしたい方は、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-1
として下さい。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
一部の界隈で騒がれている（らしい）
統計的かな漢字変換のＮグラム方式が、そんなに良いのか、
と気になったので（その２）、
読み仮名ベース変則単語 変則２グラムを実装してみた。
その２と言うのは、
その１が読み仮名ベース文字 変則２グラム、
その２が本日の読み仮名変則単語 変則２グラム。
何が変則かと言うと、
助詞（Anthy で言う所の付属語）は
２単語以上連続していても１単語と数えているので。
文を変換する際、コーパスに該当する内容が全く見つからない場合、
文節数最小法と等価になります。
${HOME}/.anthy/conf に
#
YOMIWORD2GRAM_MODE true
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-5
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-8
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSUDIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_UCDIC 0.0e-1
#MBR_MODE_LATTICE_BIASPROB_BY_OCHAIRE 6.6e-1
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2KY 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2T 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2D 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_PRE_CORE 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_CORE_POST 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_PRE_CORE 0.0e-12
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_CORE_POST 0.0e-12
LATTICE_BIASSCORE_BY_COMPOUND 0.0
LATTICE_BIASSCORE_BY_CORPUSUDIC 0.0
LATTICE_BIASSCORE_BY_UCDIC 0.0
#LATTICE_BIASSCORE_BY_OCHAIRE 1000.0
#LATTICE_BIASSCORE_BY_LEARNEDFREQ 10.0
#LATTICE_BIASSCORE_BY_DEPHISTORY 5.0
#
を追加すると、
読み仮名ベース変則単語 変則２グラムモードで文節区切りを行ないます。
100文の変換所要時間を見てみると……、
MBRダイクストラ : 3.5秒
読み仮名ベース文字 変則２グラム : 3.1秒
読み仮名ベース変則単語 変則２グラム : 3.7秒
MBRダイクストラより遅くなっているし……。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
文頭／文末の確率計算をちょっと修正。
秋月の DC-DC Step Up レギュレータを使う際に、
ヘッダーピンがじゃまなのでニッパで切った。
で、配線つないで電源入れても出力が出てこない。
テスタで追っかけてみた所、
ヘッダーピンをニッパで切った付近のパターンが一緒に切れて断線していた。
ああ…… orz
Fri,02 Sep,2011の続き。
ふと気づくと半年以上あいているのだが。
以前買った 5mm 砲弾型 UV-LED 365nm 10個セットを使って、
今更ようやく懐中電灯＊２個に組み立てた。
自作と言うか、組み立てたと言うか、
既存の 100円 １玉 白色 LED マグライトをベースに、
LED 増設の穴を掘って、
玉を UV-LED に交換して３玉付けた物と６玉付けた物の２種類を用意して、
DC-DC 付けて昇圧して、
しただけだが。
定格通り 約 20mA で駆動したのだが、 秋月の DC-DC の出力電流が足りないらしく ３玉でも６玉でも明るさが大して変わらなかった。 いやまあ出力電流が足りないのは 事前に秋月の web サイトのカタログを見て知ってはいたけれど。 それでも微妙に６玉の方が明るくはあった。 しかし６玉でもホルキンで買った 電池 6V 直結 １玉 100mA オーバードライブな UV-LED キーライトと 同じ位の明るさだった。 概算で３玉が 60mA、６玉が 120mA、だから、そんなものかな。 定格越え５倍駆動なキーライト、よく焼損しないものだなぁ……、 寿命が１万時間とか数千時間とかに縮まっているのだろうか。
あと、定格駆動でも青紫色に発光しているのが見えた。
赤外線 LED だと発光が全く見えないので、
同じ感覚で
紫外線 LED も発光が見えないものと思い込んでいたのだけれども。
そんなものなのかな。
データシート見てみればいいのだろうけれど。
紫じゃなくて青紫色に見えるのだよなぁ……。
紫外線で発光するインクもちゃんと発光する辺り、
紫外線もちゃんと出ているのだろうけれど。
なんか変な感じ。
なお、紫外線保護眼鏡無しで直視は危険が危ない。
Wed,12 Feb,2020に続く。
オチがついていない気がする。
GearHead2 とか GearHead Arena-R とかに関して、
「プログラムはわからないけれど翻訳はできる」（意訳）と
言う方が したらば にちょくちょく現れるっぽいので、
プログラムの UTF-8化だけでもできるかどうか試してみた。
そしたら GH2 は、あっさり対応できた。
しかも文字列の 255Bytes超過にも
もとから対応済だった。
本音の所は、 未完了のソフトウェアに対するパッチは作りたくないんだけれども。 本家の GH2 が１年半以上止まっていると言うのと。 翻訳マダーと言う人がちょくちょく現れるので、 じゃぁ自分で翻訳してみて下さい、と言うのと。
I18N とか L10N とか M17N とかまでやる気力は無し。
GearHead Arena-R は、 コンパイルは通るものの、実行すると
LoadSAttScripts ERROR: [string "LoadSAttScripts"]:1: unexpected symbol line: " GG_PERSONANODE = -23;" LoadLuaConstants ERROR: attempt to call a string value GH_INIT ERROR: gamedata/gh_init.lua:242: table index is nil Register ERROR: Cannot register before LUA_IS_GO Register ERROR: Cannot register variables before LUA_IS_GO HandleTrigger ERROR: attempt to call a nil value
とかでて lua がこける。
本家 Forum によると、
「FreePascal の amd64版だと駄目。i386版を使って」（意訳）
らしい。
手元のマシンは amd64版の OS しか入れていないので、
UTF-8 対応とか日本語対応とかの作業以前に
本家英語版の再現すら駄目っぽい。
amd64上の OS から i386板の FreePascal を駆動できないかと
fpc をいじってみたが、
amd64版と i386版の相互クロスコンパイルはできないっぽい。
FreePascal を
i386 のエミュレーションとか wine32 とかで実行してまで
開発する気力も無いし。
Sat,19 Oct,2013に続く。
チマチマ作業していたら、 %JS %JF %JG 対応できたっぽい……。 行き当たりばったりな作業の仕方をしているのでかなり難があるけれど。
２年半ぶりに Pascal をいじったのだが、 プログラミング言語って案外覚えているものだなあ。 GearHead1 のソースコードの 何処に何をどうやって改造したかの方は覚えていないけれど それは何の言語の何のプログラムであってもフツーだし。 言われるまで %JS %JF %JG の存在すら忘れていたし。
うーん、
手放しで褒められるほど、良くは無い感じ……。
alt-cannadic/alt-depgraph にする前の Anthy の MBR-Viterbi よりは
許せる様な気がするけれど。気がするだけ。
alt-cannadic/alt-depgraph を搭載した MBR の方が
良い様な気もしなくもないけれど変わらない気もするし。
Ｎグラムは、２桁違いのコーパスが必要なのかなぁ。
１万６千文位のコーパスじゃ足りないのかなぁ。
%JS %JF %JG と UTF-8 な文字を続けて書くと空白が入るとかで。
series と gamedata で、文字列のパースしている箇所が違うのね orz
gamedata は余計な空白が入らない様に修正済みだったのに、
series は忘れていたというか気付かなかった。
直した。
boxed lunch
lunch box と言うと、 弁当箱（中身を含まない、箱だけ）に なってしまうらしい。
Fri,28 Aug,2009、 の続き。
タイムスタンプをリビジョン表記に使う： svn propset --revprop svn:date "2009-07-01T00:00:00.000000Z" -r 123456 svn co とか svn export したディレクトリを、ファイル名順ソートで tar に固める：find anthy-9100h \! -type d | grep -v "/.svn/" | sort | tr \\n \\0 | xargs -0 tar -cvf - | lzma -9 > tar.lzmasourceforge.jp にあるレポジトリをレポジトリのままローカルにコピーする： cd path-to-repository svnadmin create gearhead1-i18n svnsync init file:///path-to-repository/gearhead1-i18n http://svn.sourceforge.jp/svnroot/gearhead1-i18n svnsync sync file:///path-to-repository/gearhead1-i18n
Wed,04 Mar,2020 追記：
tar の引数を xargs で渡すのはマズい。
Sun,25 Aug,2019、 Wed,04 Mar,2020、 に続く。
Mac で hengband-lua 2.0 が動かないと聞いて、 もしかして GearHead Arena-R を amd64 で動かすと lua がこける件の手がかりになるか、と思って追跡調査してみた。
結論から言うと lua は関係無くて、 amd64 非対応なバグ？だった。 原因箇所のソースコードを見てもらった方がはやい。
diff src/h-type.h.org src/h-type.h --- src/h-type.h.org 2012-05-05 14:02:28.000000000 +0900 +++ src/h-type.h 2012-05-05 14:28:13.000000000 +0900 @@ -113,17 +113,12 @@ /* Signed/Unsigned 16 bit value */ -typedef signed short s16b; -typedef unsigned short u16b; +typedef int16_t s16b; +typedef uint16_t u16b; /* Signed/Unsigned 32 bit value */ -#ifdef L64 /* 64 bit longs */ -typedef signed int s32b; -typedef unsigned int u32b; -#else -typedef signed long s32b; -typedef unsigned long u32b; -#endif +typedef int32_t s32b; +typedef uint32_t u32b;
amd64 だと L64 は undef になっている。
うむ。見事にアレだ。
この型宣言のせいで乱数生成関数が 64bit で乱数を生成してしまっていて、
その返値が 32bit で収まる様になるまで乱数生成を繰り返している。
しまった。 #include <stdint.h> を忘れてる……。
で、これって *band 全般に該当するのではないかと思うのだが、
ちょっと探してみたら
angband の総本山とか日本語化サイトとか、
あらかた消滅してしまっている。
*band の時代は過ぎたのか……。
zangband は SIZEOF_LONG_INT > 4 なら L64 を define する 方向で直してあり、 zangband の www.koders.com は #if (defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L) || defined HAVE_STDINT_H なら uint16_t/int16_t/uint32_t/int32_t を使う方向で直してあった。
mangband は L64 を define する方向で直してあり、 mangband の trunk は #define __STDC_FORMAT_MACROS な 方向で直してあった。
って、一人で *band 全部調べるのは無理だぞ。
Mon,07 May,2012 追記：
angband の総本山は見つかった。
stdint.h を使う方向で直してあった。
となると、hengband だけが追従できていないのかな？
bool : stdbool.h
uint*_t / int*_t / uint_least*_t / int_least*_t / uint_fast*_t / int_fast*_t / uintptr_t / intptr_t / uintmax_t / intmax_t : stdint.h
INT*_MIN / INT*_MAX / UINT*_MAX / INT_LEAST*_MIN / INT_LEAST*_MAX / UINT_LEAST*_MAX / INT_FAST*_MIN / INT_FAST*_MAX / UINT_FAST*_MAX / INTPTR*_MIN / INTPTR*_MAX / UINTPTR*_MAX / INTMAX*_MIN / INTMAX*_MAX / UINTMAX*_MAX : #define __STDC_LIMIT_MACROS して stdint.h
PRId* / PRIdLEAST* / PRIdFAST* / PRIdMAX / PRIdPTR など : #define __STDC_FORMAT_MACROS（C++）して inttypes.h （自動的に stdint.h を読み込む）
FreeBSD 10-CURRENT を５月５日号に更新したら
mlterm が動かなくなった。
mlterm をビルドする際に -DDEBUG して、
エラーメッセージの詳細を見てみたら、
WARN: [ml_term.c:184] ml_pty_new failed. DEBUG: [deleting child windows] DEBUG: [deleting child windows] DEBUG: [deleting child windows] DEBUG: X connection closed. WARN: [x_screen_manager.c:1334] open_screen_intern() failed. WARN: [main_loop.c:453] open_screen_intern() failed. Unable to start - open_screen_intern() failed.
とか言ってくる。
意味が判らなかったのでデバッガで追跡。
/dev/ptyp0 が無いのが原因らしい。
どうも FreeBSD が /dev/?ty?? から /dev/pts/? に移行した為に
/dev/ptyp0 が無くなったらしい。
/boot/loader.conf で pty_load="YES" したら、
/dev/ptyp0 が使える様になった。
FreeBSD にも uim-1.8.0 が来ていた。
アップデートしてみたのだけれども、
ステータスポップアップが画面外に表示される事が有るのと、
モードに連動したステータスポップアップの表示／非表示が機能しないのが、
1.7.x系と変わらなかった。
と、言う訳で、 uim のステータスポップアップ改造パッチ 更新。
FreeBSD 10-CURRENT を５月５日号に更新したら、 スレッド回りだかなんだかで Bus error の誤爆が出まくる様になった。
http://lists.freebsd.org/pipermail/freebsd-current/2012-May/033656.html らしい。
/usr/src を r235068 に更新して、 /usr/src/lib/libthr で make obj depend all install したら、 治った。
CURRENT はこの手の問題があるからなぁ……。 でも Intel_GPU 使うには CURRENT にするしかないしなぁ……。
MS-Windows での GDI での ASCIIモードにて、 バッキングストア（ダブルバッファ）にして、 ちらつかない様にした。
GearHead-1 だと、 バッキングストア（ダブルバッファ）にしなくても、 わりとちらつかない様な表示仕様だったのだけれども、 GH2 になってから表示の仕様が変更されて、 バッキングストア（ダブルバッファ）前提の実装になっていた。
MS-Windows での GDI での ASCIIモードでの バッキングストア（ダブルバッファ）を UNIX系に再移植。
ASCII での表示内容を一旦バッファに溜めて、 再表示実行時に UTF-8 を正しく表示できる様に再加工して Write()。
「正しく表示できる様に再加工」とは。
FreePascal のコンソール出力関数に UTF-8 を流し込むと、
UTF-8 の所謂全角１文字を ASCII ３文字相当として扱われてしまい、
例えば漢字 60文字を表示しようとすると、
ASCII 180文字ぶんとみなされてしまい
横幅 132文字のコンソールの場合だと
途中でぶった切られて改行されてしまう。
そこで、
UTF-8 の所謂全角を表示しようとする場合には、
カーソルを一旦上下の行に移動して再度元の行に戻してから、
１文字毎に区切り表示する、
と言う事をやっている。
FreePascal内にカーソル位置をキャッシュ？して
カーソル位置の変更の最適化を行なっているらしく、
カーソルを一旦別の行に動かさないと、
FreePascal内のカラム位置の計算が狂うらしいので。
このへんは、GearHead1 の I18N化がらみで得たノウハウ。 GH2 の ASCIIモードで表示位置がメタメタに狂うのを見るまで、 すっかり忘れていたけれど。
fvwm2 上で firefox を使っていると、 ダウンロードダイアログが マウスカーソルを強制移動させてしまい 困っていたのだが、対処法がようやく判明。
設定ファイルに以下を追加。
DestroyFunc UrgencyFunc AddToFunc UrgencyFunc + I Iconify off + I Raise
何の事は無い、 fvwm2 のデフォルト設定で、 わざとマウスカーソルを強制移動させていただけだった。
わかってしまえば簡単なのだけれども、 これがわかるまでに gdb でトレースまでしたと言う……。
Fri,22 Jul,2011、 Wed,03 Aug,2011、 Thu,04 Aug,2011、 Thu,11 Aug,2011、 Fri,18 Nov,2011、 Sat,28 Jan,2012、 の続き。
Intel_GPUパッチが遂に HEAD(10-CURRENT) に commit されたらしい。 r235859 だそうだ。
KMS なドライバも i915 と drm から、 i915kms と drm2 に、 変わったらしい。
５月中旬頃の Intel_GPUパッチを使っているけれど、 ４月以前の Intel_GPUパッチみたいな不安定さには遭遇していない。 以前はちょくちょく起動失敗したり フリーズしたりしていたけれど。
とか書いている時にフリーズ起こした。
Sat,09 Jun,2012 追記：
FreeBSD 10-CURRENT の HEAD に更新してみた。
xf86-video-intel を
xf86-video-intel-2.17.0_1
に更新しないと Xorg が刺さった。
loader から load i915kms.ko すると、
起動画面が表示されないのでわけがわからなくなる。
xf86-video-intel を 2.17.0_1 に更新すれば、
Xorg 起動時に自動で kldload してくれるので、
その方が無難そう。
６月15日(金)〜17日(日)にかけて、
非定期計画メンテナンスが行われる予定です。
メンテナンス中は、
本サイトに接続できなくなったり、
します。
acer AS3820T-N52B は
第１世代 Core i5 でカタログ上は 2.4GHz まで出るのだけれども、
2.266GHz を越えるとサーマルシャットダウン起こすので、
2.133GHz をリミットにして常用している。
Hyper-Threading も切りたい所だけど、
HT 切るのに対応していないので切れない。
その状態だと、
make buildkernel には４０分、
make buildworld には４時間、
かかった。
…… Core2 Duo 2.1GHz クラスの 1400x1050 SXGA+ な中古なら、
新品の 3820T-N52B 1366x768 の半値で買えたのか……。
今更だけれど。
あーでも Core2 Duo 近辺の世代だと液晶バックライトが蛍光管なのか。
中古の蛍光管式のバックライトは寿命が怖いしなぁ。
プラモデルのスミ入れに、
deleter ネオピコライン 0.03mm (黒)(水性顔料) ￥160- を使ってみた。
.Too コピック マルチライナー 0.03mm (黒)(水性顔料) ￥210- じゃないのは、
入手性と値段の問題。
近場の大きな文房具屋ではネオピコラインしか売っていなかったし、
たいして使わないなら安物でもいいや、と。
マックスファクトリー コピックモデラー 0.02mm (ウォームグレー)(水性顔料)
￥230- じゃないのは、
色の好みと値段の問題。
ニュートラルグレーが好みなのだが、
グレーだと
0.02mm ウォームグレー か
0.03mm ウォームグレー か
0.03mm クールグレー しか売っていない。
ガンダムマーカー スミ入れ用（極細）グレー/ブラック(油性)は
スミ入れ後にはみ出した部分を拭き取る事前提だったけれど、
0.03mm ブラック(水性顔料) だと拭き取り不要で綺麗に仕上がった。
ただ、ブラックだけあってグレーよりも濃い。
白とか黄色とかにブラックだと濃くて好みに合わない。
あとは、
油性と水性顔料の違いが
どんな感じなのかよく判らない点が残っているかな。
……ガンダムマーカー スミ入れ用（極細）グレーを紙に書いてみたら、 なんか濃い目のクールグレーな気がしてきた。
Sat,18 Jan,2014、 Wed,03 Dec,2014、 Fri,29 Sep,2017、 Sat,13 Jul,2019に続く。
一応完了らしい。 乙です ＞ wheel
Tue,07 Feb,2012、 の続き。
pefs 上で tar -cf を実行すると
「tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device」
が出るのだが、
これって何だろう？
webで検索しても情報が見つからないし。
メッセージの内容からすると、
pefs が SEEK_HOLE に対応していないっぽい雰囲気がするけれども、
はてさて？
pefs の Commit History 見たら何か書いてあった。
pefs: Prevent userland from assuming SEEK_HOLE/SEEK_DATA are supported
4db924ea65 Browse code
March 25, 2012
らしい。
Sat,06 Mar,2021、 Fri,30 Apr,2021、 に続く。
黒鉄色 : こくてつしょく
黄橙色 : おうとうしょく
暗緑色 : あんりょくしょく
濃緑色 : のうりょくしょく
青竹色 : あおたけいろ
焼鉄色 : やきてついろ
明灰白色 : めいはいはくしょく
情報源 : http://www.excite.co.jp/News/bit/00091135197457.html
httpd に、↑の様な謎のアクセスが去年くらいから来ている。
サーバメンテのついでに調べてみた。
最初に来たのは 26/Jun/2011:05:24:14 +0900 だった。
user-agent は
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.1)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; YTB730; GTB7.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1; YJSG3)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB7.1; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR3.0.30729; .NET4.0C)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB7.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E; InfoPath.2)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB7.1; EasyBits GO v1.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0 .30729; Media Center PC 6.0)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; .NET4.0C; .NET4.0E; BRI/2)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
など。
必ず Trident が入っている。
って、MSIE は必ず Trident が入るのか。
はてさて、何だろう？
WBS にヨドバシカメラが出ている。 珍しい。 いつもならビックカメラを出すだろうに。