弾圧される前に引っ込めます。

訂正
重大な訂正。

realsched.exeはプログラム名までインストール時の説明に書いてあったので、無断使用ではない。
インストール時に選択の余地がないだけである。

2004年02月06日 00時56分11秒

無断使用
いつのまにか

iPodService.exe
realsched.exe

どちらも、ダウンロード時から使用時にいたるまでこれらのプログラムを常駐させるとは明確には説明されない。説明があったとしても、iPodと連携する機能とか、アップデートの自動確認機能というだけで、プログラムが勝手に起動されるようになるとはかいてない。インストールに同意しただけでどんなプログラムを常駐させるかの決定権を譲渡したことになるというような理不尽な仮定が成り立つのでない限り、
計算機の無断使用ではないか。

realsched.exeの方はアップデートの自動確認をやめれば止まりそうだが、iPodserviceは止める手段が提供されていないのでたちが悪い。
またappleか。

2004年02月06日 00時49分02秒

xwnmo + flash6
http://z1.plala.jp/download/XF86up/
にまとまっているし、パッチをあてたバイナリも配っている。
xwnmoの最新版ではXSetICFocusパッチをあてなくても落ちなくなっていた。
一方、XFree86のCVSにはXSetICFocusパッチがとりこまれた。
Plamoのメーリングリストをみるとhttp://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2961#c19
を報告するという話があったので、その結果らしい。

2004年01月05日 23時21分28秒

宣伝のために客に苦行を強いる
プレゼントがどこでつきるかとか、何時間待ちの見込みとか、列を離れる決断ができる情報を提供しないことにより5000人以上を並ばせたのは、

宣伝になる話題作りのためなら、客に苦痛を与えても気にしない

ということだと推定する。

人数の多さに浮かれていて、客が苦痛を感じていることに気付きもしなかった

という可能性もある。いずれにせよ、

客の気持など知ったことではない

ということであろう。

そんなわけで、OSXは欠陥だらけとは言え多少は利点を評価しないわけでもないが、
会社に関しては、圧倒的に悪い評価しかできない。

2003年12月04日 22時25分56秒

国外逃亡
23日まで米。

2003年11月15日 00時15分59秒

夜間無灯火犯罪自転車
一台目信号無視して横から体当たりをしかけてくる。
こちら(信号が青の側)が停止して回避。
過失は100%向こう。

二台目歩道で正面から体当たりをしかけてくる。
こちらは停止したが、相手は減速せず衝突して停止。
相手が回避していないことは、こちらもキチガイの行動を予測できず左右への回避ができなかったことで相殺するとしても、減速しなかった分相手に過失が残る。

が、そもそも、違反行為を指摘しても無視して逃げ去ったので、過失ではなく、意図的な当て逃げ(一台目は未遂)と断定。

当て逃げはともかく、無灯火はつけ忘れではないと推定できるので、故意に危険な走行をしていたと断定してよかろう。

2003年10月20日 22時54分48秒

不完全性
.macへの問い合わせだったが、
契約内容すら不完全なのに一日単位の精度要求するだけ無駄だろう。

2003年10月19日 23時46分55秒

一年364日あるいはうるう年でも365日
概要契約期間が一日足りません。

日付: 2003.09.09, 10:02:25 JST
件名: お客様の .Mac メンバーシップはあと 30 日で有効期限が終了します。
というメールでは、
「October 08, 2003 PDT に有効期限が終了いたします。」
となっており、前回の契約は 2003/10/08までで、
今回の更新契約は2004/10/09から2004/10/08が利用期間だと思っていたのですが、
日付: 2003.10.07, 18:42:19 JST
件名: ご更新ありがとうございます
というメールでは、
「2004/10/07 JST に更新されました。」
となっており、自動更新のチェックを外した状態でのアカウント情報の表示も
「2004/10/07 JST に有効期限が終了します。」
で、2003/10/08から2003/10/07が契約期間になっているようです。

つまり、前回契約の最終日と今回更新の開始日が重複しており、
前回もしくは今回の契約期間が一日短くなっているように見えます。
（PDTとJSTの時差かとも考えたのですが、説明がつくどころか、
　期間短縮が一日と１７時間ということになってしまいます）

厳密には終了時刻まで規定していませんでしたし、今後JSTで更新日を判断するなら
時差による17時間の差は今回だけなので、適用時間帯変更による一回限りの短縮ということ
であれば容認することも考慮しますが、

契約の最終日と更新の開始日が重複し、更新日が一日早くなるのは、
「契約期間一年ではなく、一年より一日すくない」
ということになってしまいます。

本当に契約の最終日と更新の開始日が重複し契約期間が一日短くなっているのかどうか
早急にご確認、返答お願いします。

前回の契約終了日は利用できなくなる最初の日で現在の終了日は利用可能な最終日であるとか、
一年は３６５日のことでうるう日があるため日付けがずれるとか、
重複はないということでしたら、一日短いというのは私の誤解ですが、
今後誤解がないように、期間・更新日・契約終了日の意味の統一と説明の掲載をお願いします。

2003年10月19日 23時43分49秒

やっぱり画期的
NAPTではなく狭義のNATなら問題ないと思われるので、NATルータがはさまっていても大丈夫という説明は間違いとは言えないだろう(BSD系なのだからNATと言ったらアドレスしかつけ換えないのが正しいのだろう)。

で、データにIPアドレスを埋め込んでいるので狭義のNATでもだめな映像音声チャットが普及しているようなので、
それにくらべれば、狭義NATを越えられるだけでも画期的と言えるかもしれない。

In fact, iChat AV works fine with many popular household routers in their out-of-box configurations.
と言う説明の「many popular household routers」というのがNAPT非対応NATルータだとは思えないが。
UPnPが怪しいがそれだと上述したNATでも越えられないやつも対応してるので画期的でなくなってしまうので、
NAPTだけどポート番号はできるだけ書き換えないルータなら繋がることが多いということなら、一応、納得できなくもないということにしてもよいかもしれない。

「household」というあたりは、セキュリティ面でも高機能な職場のルータの場合は問題になりそうなことを示唆しており、
過度の期待をして不満をもつことにならないようにと配慮したのだろう。

(以前の職場で、ルータで分断されたVLAN間で映像音声チャットをするためにiSightを購入したのに繋がらなくて泣いている人には手遅れだが)

2003年10月10日 00時30分58秒

アップルのX11クライアント
http://www.apple.co.jp/macosx/panther/index.html
によればX11クライアントが完成したそうだ。

Pantherには、UnixアプリケーションのためのX11クライアントの完成版、強化されたNFS/UFS機能、FreeBSD 5の最新機能、ポピュラーなLinux APIへの対応、IPv6その他の標準規格のサポートが含まれています。

http://www.apple.com/macosx/
では
Panther improves the open-standard, industrial-strength, UNIX-based foundation and now includes X11 for Mac OS X. Along with an enhanced Terminal and updated open source projects such as Python, FreeBSD 5 commands and libraries make Mac OS X Panther the ultimate UNIX platform.

クライアントとか完成版とかは見当たらない。
アップルジャパンが独自のX11クライアントをつけるのだろうか。

2003年10月09日 22時42分46秒

リサイクル
生ごみ・糞尿を肥料にする

というのが、リサイクルとかエコロジーとかの話で出てこないのはなぜだろう。
農地の中で暮していたときは当たり前だったのだが。

2003年10月02日 01時37分42秒

修正・更新・機能の拡張に対応し
この表現で、コンピュータに詳しくない人が、修正をしなければならない欠陥があると推定できるだろうか。
また、推定したとしても、欠陥とは無縁な仕様変更でも修正と表現することはあるので、欠陥の修正だと確信はもてないだろう。

このような、欠陥の存在をあえて伏せておいたのでは、
「現状の機能で十分だから、わざわざ手間隙かけてWindows Update で新機能を追加しなくてもよい」
と判断されてもしかたないだろう。

既知の欠陥を利用者に伝えないで、「対策に積極的に取り組んでいます」と言えるのか。

Windows Updateで更新される内容はwebで公表しているという反論が考えられるが、
せいぜい脆弱性という表現しかしていないのでは欠陥を伝えているとは言えないだろう。

両立できないセキュリティと利便性もあるので脆弱性は欠陥ではないという主張もあるかもしれない。
確にそういう脆弱性もあってユーザーが利便性との兼ね合いで敢えて脆弱な状態を選ぶ場合もあるが、
バッファーオーバーフローによる脆弱性の場合、原因はデータサイズ等のチェックをしていないことで、これは、利便性とは無関係の単なるプログラムの記述ミスあるいは手抜きであり、欠陥以外の何物でもない。

2003年09月20日 01時02分01秒

適用できないパッチ
KB824105
823559

が何度やっても失敗する。
緊急とか、すぐあてろとかいうなら、あてられるようにしろ。
windowsupdateからリンクされている詳細情報を見ても、windowsupdateに失敗する場合は全く想定しておらず、手動ダウンロードするのも一苦労である。

手動ダウンロードしても失敗する。
どうやら、展開場所が問題のようである。
そんなにパス決め打ちが好きか?

2003年09月16日 01時02分55秒

欠陥を放置する.mac
にせMIMEの件は報告したのに、また送ってきた。
ようするに、FeedBackに欠陥を報告しても相手にしないのだろう。
個人向けのコンピュータ業界では、

欠陥を放置する

というのが常識なのか。

2003年09月14日 10時30分38秒

xwnmp + flash6
googleで検索してすぐ見つかるところでも取り込まれたようなので、検索能力のある人には行き渡るだろう。
知人以外でここにたどり着く人はいないと思うが、誤解するかも知れないので念のため書いておくと、
ここの方がbugzilla(jp)への投稿より早いが、ohnoyouがここを見て勝手に自分名義でbugzillaに投稿したのではない。
（文面からdroとohnoyouの関係を推定すればどういうことかはわかる）

2003年09月10日 01時29分40秒

xwnmo + flash
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2961
に投稿しておいた。
で、momongaには取り込まれるようだ。

2003年09月07日 14時30分00秒

XFree86 wnn7 flash6
XSetICFocus()
でSegvのようなので調べてみると、引数icの内容を参照しているのに、NULLが渡されていた。
呼び出し側でチェックするという仕様なのかもしれないが、flash6のソースは手元になく修正できないので、XSetICFocusの方でNULLチェックをするようにしたらWnn7のxwnmoを使っていても落ちなくなった。
flash6がどういう意図でicがNULLでXSetICFocusを呼ぶのかわからないので、何もしないことによる副作用は不明。icがNULLならそもそも呼ぶ必要がないのだから無視してよいとは思う。
RedHat9のXFree86-4.3.0-2へのパッチは下のような感じ。
xc/lib/X11/ICWrap.cには他にもicをチェックしないでic->core.imで判定している関数がたくさんあるので、他も直す必要があるかもしれない。

*** xc/lib/X11/ICWrap.c.org 2003-08-30 16:16:24.000000000 +0900
--- xc/lib/X11/ICWrap.c 2003-08-30 16:14:05.000000000 +0900
***************
*** 346,351 ****
--- 346,352 ----
XSetICFocus(ic)
XIC ic;
{
+ if(ic!=NULL)
if (ic->core.im)
(*ic->methods->set_focus) (ic);
}

2003年08月30日 16時45分00秒

wnn7
で、パッチをあててみたが、改善せず。
Wnn7のxwnmoの場合は別な原因か。
(momongaでもWnn7のxwnmoとの組合わせは解消しないという報告が出ているので、うちだけの問題ではないだろう)

2003年08月29日 23時40分38秒

xim
kinput2以外のXIMでflash6がcrushするのはXFree86のバグらしい。
http://bugs.xfree86.org/show_bug.cgi?id=618

2003年08月27日 22時23分45秒

欠陥品販売
知人に今日届いたwinXPのPCが早速感染したらしい。
パッチ・ウイルス対策ソフトをダウンロードしようとしていたらしい。

対処法がいきなり間違っているのは知人の過失であるが、

既に知られている欠陥を修正しないで販売する

のはよいのだろうか。
欠陥免責条項も製造側が気が付いていなかった欠陥のことなのだから、判明した後は修正版を販売するべきではないか。
出荷済のものを回収するのは大変でも(他の業界ならやると思うが)修正パッチを収録したCDを追加するなら店頭にならんだ後でも容易ではないか。

ソフトウェアは他の商品より欠陥を事前に見つけるのが困難だという言訳がとおるとしても(これだけでも通常の物品販売の常識から掛け離れているが)、
他の商品より容易な修正を販売時点でわかっているのに製造者・販売者が行なわずに消費者に責任転嫁するのまで許されるのか。

2003年08月20日 23時01分46秒

port135
10回/時くらいport135にアクセスが来ている。
自分のプロバイダより、隣のプロバイダ(IPアドレスの第二バイトが1違う)からのほうが多い。
多いというのは半数がそこから。
自分のプロバイダからは1/4。

2003年08月14日 20時20分57秒

error表示だけの運用
今（2003年8月10日午後7時44分）では、

Did not receive any response from application. It is possible that the application does not exist, or that the requested url is incorrect.

と表示するだけになった。

www.apple.co.jpの方では

.Mac サービスは現在通常運用を行っております。

となっているので、エラー表示するだけでも通常運用なのだろう。

これで年間12800円とるのだからすばらしい。

2003年08月10日 19時41分57秒

にせMIME
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64

の後に8bitデータが並んでいた。当然、base64としてデコードするのは不可能であった。
試行錯誤の結果、ただのUTF-8として解釈すると日本語として読めることがわかった。

つまり、base64といいながら、UTF-8がそのまま(漢字やひらがなが大半なのでほとんど8bitデータ)使われていた。

アップル（ドットマック）はすごすぎる。

2003年08月10日 00時09分58秒

ムーアもびっくり
焼けつくようなバンド幅
Power Mac G5の非常に高バンド幅のシステムアーキテクチャは、各プロセッサに対する1GHzフロントサイドバスが16MGB/秒という飛躍的なスループットに貢献します。

http://store.apple.com/0120-APPLE-1/WebObjects/japanstore.woa/80403/wo/oV2jmAqdKxuM2cQ4VNHLbTqUWrN/0.0.7.1.0.5.21.1.2.1.2.0.0.1.0

一世代でバンド幅が10000000倍とは飛躍しすぎ。
プロセッサより先に、会社の方が焼きついたのだろう。

DDR400と1GHzフロントサイドバスの整合性も謎。

公表しているベンチマークでもわかるように、定量的な議論ができない会社なので仕方ないか。

2003年08月09日 21時58分58秒

著作権を侵害する行為とみなされない
munou氏の投稿で指摘されたように、

著作権法　第百十三条２　プログラムの著作物の著作権を侵害する行為によつて作成された複製物（当該複製物の所有者によつて第四十七条の二第一項の規定により作成された複製物並びに前項第一号の輸入に係るプログラムの著作物の複製物及び当該複製物の所有者によつて同条第一項の規定により作成された複製物を含む。）を業務上電子計算機において使用する行為は、これらの複製物を使用する権限を取得した時に情を知つていた場合に限り、当該著作権を侵害する行為とみなす。

ということなので、かりにSCOの主張が著作権の侵害であれば、たとえ事実であっても、既に使用権を得ていれば著作権を侵害する行為とみなされない。
米国ではどうかしらないが、日本ではだいじょうぶだろう。

では、今後新規に利用を開始すると著作権を侵害する行為とみなされるのか。抜け道を考えてみた。

1 「情を知つていた」といえないと主張する
現時点では一部の企業には脅迫状を送付したようだが、多くのLinuxユーザには正式に連絡がいっておらず(少なくとも私にはきていない)、SCOの主張として報道された記事を読んだだけである。
報道は公正であることは道義的に期待されてはいるが、個々の報道の信憑性は何ら保証はないはずである。
そこで、報道内容は知っていたが、それが事実であるかどうかはわからなかったので、著作権を侵害しているとは考えなかったと主張したら、情を知らなかったことにできるのではないか。

2 使用する権限を取得済であると主張する
Linux kernelは公表された時点で全ての人に使用許可を与えているので、SCOの主張を知る前に公開されていたバージョンは使用する権限を得ていたといえないか。
GPLはソース・バイナリ取得時に契約が成立するという説をとると、成り立たない。

2003年08月04日 22時50分57秒

画期的
appleのiChatAVの説明によると、画期的アプローチでNATルータを越えられることになっている。
技術情報にもNAT対応したのでポートを開ければよいとかいてある。
が、ポートを開けただけでは使えない事例が複数ある。
どうやら、ただ開けるだけではだめで、ポート番号を変えない等の設定が必要なようである。
UPnPで解決した例も多いようで、パケット解析してUPnPを使用しているのを確認した人もいるようである。
UPnPならそう書けばみんな苦労しないのに。
UPnP対応しただけなのを画期的アプローチなどと大見得きってしまって引っ込みがつかないのか。
それとも、画期的アプローチに失敗してUPnPを代わりに採用したのか。
それにしても、嘘・間違い・誇大な表現で、顧客に誤解・混乱・無用の労力をさせるのは、いい加減やめてほしい。

2003年07月27日 22時14分26秒

ジャイアン
IBMがAIXに独自開発追加したコードもSCOのライセンスが必要だと主張しているようだ。
例えばJFS。

UNIXはSCOのもの、UNIXに追加されたものもSCOのもの、という主張か。

2003年07月09日 23時16分03秒

第三者
SCOの主張では、著作権侵害では善意の第三者は通用しないらしい。
(日本ではどうかしらない)

2003年07月09日 23時06分16秒

.macの現状

<2993>?<06>??20??
2:30am pdt
Web?????????.Mac??????????????????????????????????????????iDisk???????iCal??????????

appleのdiscussionボード（登録制）にしか掲載されない障害情報より。
文字化けしているのはもとから（MozillaFirebird,safari,IEで確認）。

2003年06月20日 19時30分28秒

クレーム拒否
ACCSのリリースの問い合わせ先は
book@accsjp.ne.jp
となっているのだが、配送エラーで届かない。

2003年06月20日 15時47分19秒

浄水器
「酸化還元とは酸化による水の腐敗を防ぐ抗酸化過程のことをいい、」
いきなりこれである。現代化学の用語の定義から覆してしまう。

「この合金フィルターにはプラス200ミリボルトの電気が流れており」
電源不要だそうなので、超伝導なのだろうか。

2003年6月16日朝日新聞朝刊の浄水器の広告より

2003年06月20日 00時52分33秒

統計でうそをつく(ACCSのでたらめ統計処理)
コンピュータソフトウェア著作権協会（ACCS）の
「－ファイル交換ソフト利用者、40万人増の185.6万人に－」
は不正な統計処理によるでたらめな数字である。

185.6万人というのはACCSの標本調査でのファイル交換利用者比率0.064と総務省の発表したインターネット利用者数2889.6万人を掛け算しただけである。
標本数は18831で標本の偏りがなければ期待値はそれなりに真の値に近いと思えるのだが、調査法は「WEBアンケートサイトにより」というだけしかわからず、標本に偏りがない保証がないだけでなく、どの程度の誤差が期待値に生じるかすら、全く不明である。
これだけなら、偏っているかもしれないというだけだが、発表資料の貧弱なデータだけでも、著しい偏りがあることがわかる。

ナローバンドとブロードバンドでの利用経験者の違いのデータによると
ナローバンド (N= 4417) 4.2%
ブロードバンド (N=14110) 7.2%
となっている。ナローバンドの標本数は23%である(304人は不明)。インターネット利用者のナロー/ブロードの比率が1/31になるほどブロードバンドが普及しているとは信じがたい。
ここで、インタネットユーザー数の母数2889.6万人の根拠にされている、インターネット接続サービスの利用者数等の推移【平成14年12月末現在】（速報）総務省平成15年1月31日」をみると、
平成14年12月末の利用者数は、
DSL 5,645,728人
FTTH 206,189人
CATV 195.4万人
ダイアルアップ 200 (11年末の約1059.4万人を100とした指数で約2119万人相当)
であり、2889.6万人のうち73%がダイヤルアップであるとわかる。ACCSのナロー・ブロードの区別が不明ではあるが、ダイヤルアップをナローとするのはよくあるので採用すると、ACCSの標本とは全く比率が異ることがわかる。ただ単に一致しないだけでなく、統計誤差を上回る、有意な差である。
つまり、ACCSの調査の標本は明らかに偏っているということである。
さらに、今回の測定量であるファイル交換利用者比率はナロー・ブロードで異っており、全体のファイル交換利用者比率の推定に影響がある偏りであることになる。
実際、ナロー・ブロード別に推定すると、
ナロー 2119万人*0.042 = 89万人
ブロード 780.6万人*0.072 = 56万人
となり、合計では145万人となり、ACCSの推定と40万人の食い違いがあり、ナロー・ブロード偏りだけで20%以上の誤差が発生していることがわかる。
同様に現在も利用している人数の推定だと
ナロー 2119万人*0.016 = 33万人
ブロード 780.6万人*0.040 = 31万人
合計64万人でACCSの推定値99万人と、35万人・35%の誤差である。

また、今回は検討するための資料が見つからなかっただけで、ナロー・ブロード以外の偏りは存在する可能性はある。つまり、ACCSの推定値の間違いはもっと大きいと考えらる。
たとえば、帯域と標本数、帯域とファイル交換利用者比率に正の相関があることを考慮すると、ネACCSの標本選択はネット利用コストと負の相関があり、結果的にファイル交換利用者に偏っていると考えられる。これをナローバンドでのフレッツISDN(定額制)利用者と従量制利用者の偏りに演繹すれば、ナローバンドの標本もさらにファイル交換利用者比率が高くなる偏りがあると考えられる。これは、ネット利用コストが少ないほどWEB閲覧に費やす時間をとりやすい、WEBアンケートに答える可能性が高い、と考えると説明がつく。

結論
185.6万人は明らかに過剰推定である。
ナロー/ブロードの比率を考慮するだけでも145万人に下方修正する必要がある。
その他の標本の偏りも考慮するとさらに少ない。

2003年06月19日 23時31分32秒

SCO対策
linuxを使用するにあたってSCOどう対応するか。

1 SCOから直接、権利侵害の警告がくるまで
何もしない。SCOの権利を侵害していることがわからないから。
SCOの発表と称するものが報道されているがどこまで本当かどうか確認できないので、SCOから直接警告がこないと、具体的にどのような権利侵害をしているのかはわからない。

2 SCOから直接、権利侵害の警告がきたら
2.1 証拠がない(ソースの特定等がない)場合
事実確認が不可能なので使用はやめない。
SCOの要求は確認できたことになり無視するのは危険なので、証拠の提示を要求する。特に、権利侵害を停止するため、カーネルソースの該当部分の明示を求める。
2.2 証拠の提示(該当部分の明示)が行なわれたら
該当部分を使わないカーネルを作る(自分では困難なら委託)。できるまでは使用停止。
これで、権利侵害状態は解消される。

3 過去の権利侵害の賠償請求されたら
善意の第三者であると主張する。

問題
1 報道をもって権利侵害の事実を知り得たとされないか。
現状では証拠は報道されていないので、信じるに足りないとする。

2.1 証拠のない差止要求は拒否できるか。
SCOのコードでない部分は使用禁止される理由はない以上、権利侵害部分を明確にせずカーネルソース全ての使用停止を要求するのは過剰請求だと主張する。
2.1 証拠隠滅阻止を理由に該当部分の公表を拒否されないか
侵害状態の解消を妨害として反論する。

3 善意の第三者の条件が不明

実際に個人に請求・訴状がくるとは思えないのでむだ。
職場はわからないが、一職員で対処することはないだろう。

2003年06月18日 01時37分42秒

あたり-や【当(た)り屋】
(3)故意に自動車にぶつかって、治療費などをおどし取る人。
三省堂提供「大辞林第二版」より

2003年06月18日 00時53分57秒

SCO
とりあえず現時点で考えていることを書き留めておく。
SCOの主張は、SCOが権利を持つUNIXコードがLinuxカーネルに盗用されている、ということのようだ。
また、盗用を隠されるから具体的には教えない、そうだ。盗用コードのないLinux(もともとそうかもしれないが)が使用されるようになれば、SCOの権利(実際にはどんな権利を持っているのかは不明だが)も侵害されなくなるのにだ。

既にいろいろな人が指摘しているように、Linuxカーネルのソースはいっぱいコピーが存在し、今から盗用コード(あるとしてもだが)を削除したところで、現在流通しているソースから全部消せるはずがない。
SCO自体もLinuxを配っていてソースを持っているはずで、不可能な証拠隠滅を阻止するために盗用部分を非公開にするというのは筋が通らない。

勝手につじつまが合う解釈を考えると、
最も単純なのは
「実は盗用コードがない」
という解釈だ。
オッカムの剃刀でこれ以上の推測は剃り落としてもよいのだが、あまりにもつまらないので、邪推する。

SCOの主張が正しいとして矛盾の少ない解釈を考える。
まず、証拠隠滅阻止のため非公開というは正確ではなく、SCOの主張として報道されている文章の表現を忠実に解釈すると、SCOの権利を侵害している状態を維持するためだと読める。
つまり、SCOが気にしているのは今までのLinuxカーネルに盗用コードが含まれていることではなく、現行LinuxユーザがSCOのコードを使っていることであるということになる。
権利侵害のないLinuxができて乗り換えられてしまうと、現時点でのSCOのコード使用者の特定が困難になるのが嫌なのだと考えると、盗用部分を(コード開発者にとっては受け入れがたい条件でしか)教えないで、盗用コード除去を阻止するのも納得がいく。
権利侵害主張しながら侵害解消を阻止するのは一見矛盾しているようだが、権利侵害の解消ではなく、権利侵害状態に対する賠償が目的であれば矛盾ではない。つまり、SCOのコードを誰も使わない状態ではなく、誰もがSCOのコードを使って金を払う状態を目指しているのなら、一連のSCOの主張も納得がいく。
ディストリビュータに配布停止を求めるよりも先に大口Linuxユーザー企業に対して警告を送りつけたことも、SCOコードをLinuxで使わせないことよりも、Linuxユーザーから金を巻き上げるのを優先した行動と解釈できる。
これは、SCOが、UNIX製品の開発・販売よりUNIXの権利で儲けるという方針転換したこととも整合性がある。
というわけで、SCOが盗用コードの公表を著しく制限しているのは、不正使用を続けさせて使用料・損害賠償を徴収するのが目的であると考えられる。

2003年06月18日 00時51分30秒

見落とし
PBG4 15" といのが初代だと気付かなかった。
指摘してくれた方に感謝。

2003年06月09日 21時53分18秒

商品価値
PBG4 初代(400と500)は買い取り金額すら出ない(sofmap)。
最近のと比べると、本体サイズ(および画面面積)以外の性能は半分以下だからしかたないか。
特にビデオチップ・メモリが貧弱なのは、表示負荷の大きいOSXでは致命的か(PBG4でQuarztExtreme非対応なのは初代だけ)。

2003年06月08日 22時54分27秒

ここまでくると
ISO-2022-JPが指定されているがでたらめ。
日本人が韓国語の嫌がらせメールを捨てるために設定したフィルタールールをかわすためか?
結局、ハングルの本文(html風)が読解不能。
目的を推測すると、
1 配送数だけしか気にしていないので、フィルタリングされなければよい
2 リンクや画像参照でアクセス数を稼ぐ
3 ウイルス
4a 日本人はハングルが読めると信じている
4b ハングルは世界中の誰でも読めると信じている
5a 嫌がらせ
5b 反日嫌がらせ
6a 日本(人)を侮辱する内容でわざと読めないようにした
6b link先が日本(人)を侮辱する内容
7 きょう(牛の権利の侵害として政党の代表者に批判された漢字一文字)人

以下ヘッダー周辺
kkk@kkk.comは詐称の可能性もあるのでふせたが、韓国の会社で登録されている。
SubjectにエスケープシーケンスはJISだがでたらめな文字列が入っており、配送経路でヘッダがこわれたようである。

Return-Path: kkk@kkk.com
Received: by xxx.xxx.xxx.xxx id 3eda928c0eb932;
Mon, 02 Jun 2003 08:55:56 +0900
Received: from xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx])by xxx.xxx.xxx.xxx with ESMTP id h51NtsCY010065
for ; Mon, 2 Jun 2003 08:55:54 +0900
Received: (from root@localhost)
by xxx.xxx.xxx.xxx id IAA07532
for xxx@xxx.xxx; Mon, 2 Jun 2003 08:55:53 +0900 (JST)
Message-Id: <200306012355.IAA07532@xxx.xxx.xxx.xxx>
Date: Mon, 2 Jun 2003 08:56:09 +0900
From: =?ISO-2022-JP?B?GyRCJTElKSUtYkOKQyEiGyhC?=
Reply-To: kkk@kkk.com
To: xxx@xxx.xxx.xxx.xxx
Subject: ( =?ISO-2022-JP?B?GyRCJSIlJiU/bjslKSUtYkIlVSU9GyhC?=
=?ISO-2022-JP?B?GyRCdjMlTBsoQg==?= =?ISO-2022-JP?B?GyRCJUEbKEI=?=
=?ISO-2022-JP?B?GyRCikMhIhsoQg==?=//=?ISO-2022-JP?B?GyRCJTcbKEI=?=
=?ISO-2022-JP?B?GyRCJSIlRJA+kDolKyE8JSMbKEI=?=!!
Received: from localhost ([61.73.160.110])
by xxx.xxx.xxx.xxx with SMTP id IAA25448;
Mon, 2 Jun 2003 08:55:17 +0900 (JST)
Message-Id: <200306012355.IAA25448@xxx.xxx.xxx.xxx>
Mime-Version: 1.0
Content-Type: text/html; charset="euc-kr[=?ISO-2022-JP?B?GyRCJUwlYCUiGyhC?=
=?ISO-2022-JP?B?GyRCJTElO3s+GyhC?="

以下略

2003年06月02日 22時01分21秒

課題
被害者側の指摘失敗の原因を考察し喫煙停止を実現する手段を提案せよ。

例1
禁煙区画の強制喫煙防止の意義を前提として煙草の火を消すことだけを指摘したのが敗因である。
そのために加害者側がその場をやり過ごして火を消さないことに固執し強制喫煙を停止するという考えに至りえなかったと考えられる。
したがって、望ましい対応は、要求内容として煙を吸わされることの停止を明確に伝えることである。

例2
加害者の言動からは、
他人に煙を吸わせていること、
無理やり煙を吸わされるのを迷惑に感じる人の存在、
を全く理解しておらず、また、理解するだけの知性も有していない可能性すらある。
万が一、自分の喫煙が他人の迷惑になっていることを理解したとしても、自分の快楽のためには他人が犠牲になってもかまわないと考えている可能性もある。
したがって、言論によって加害者側が自ら強制喫煙を停止するとは考えがたい。
被害者側の失敗はそもそも言論が通じると考えたことである。
どのような強制喫煙加害者にも有効な停止策は被害者が煙草の火を消すことである。
ただし、対象の煙草は加害者の財物であり、損傷を加えずに消火は困難なため、被害者側が器物損壊の加害者になる可能性もある(喫煙被害は即座に必ず身体的傷害につながらないので緊急避難の対象になるとは考えにくい)ので、その場の強制喫煙被害は停止できても刑事罰・民事賠償を覚悟する必要がある。

2003年05月26日 23時49分26秒

強制喫煙被害者の言動についての考察
1aから4aまでは妥当な指摘をしているのに、最後5aは強制喫煙加害者と同次元の感情の発露に過ぎず、
全ての議論がだいなしである(もともと加害者側の発言が論にあたいしないが)。

また、最終的に禁煙区画での喫煙を阻止できず、指摘を開始した目的を達成できていない。
加害者側が禁煙区画に関して理解を深めたとも考えがたく、被害者意識をもたせたことは、後退と言える。

結論
今回の指摘は失敗である。

2003年05月26日 23時11分55秒

喫煙強制者の言動についての考察
1 1bについて
3bにより歩いていく先に灰皿があることを知っていたと推定される。
この駅のホームは喫煙所に灰皿が設置されていたこと、さらに灰皿の位置を把握する程度には駅の構造を知っていたことから、
喫煙所以外禁煙であることだけ知らなかったとは考えがたい。
つまり、禁煙であると知りつつとぼけてみせたと考えられる。

2 2bについて
直後の行動と矛盾しており嘘である。3bを併せて考えると、今というのは灰皿のある床とまで歩き続ける間だと考えていた可能性もある。

3 3bについて
言葉は灰皿がなければ火を消せないという主張であるが、考察1で推定したように灰皿のある所が喫煙所であることを知っていたとすると、灰皿がある所まで行けばそもそも消す必要がなくなるとわかっていたと考えられる。
つまり、考察2の後者の場合でも、なしくずし的に火を消さないで済ませようとしていたこととなり、「消す」という発言は嘘だったことになる。
身ぶりは代替手段として床に捨てて踏み消すことを示唆していると考えられる。それに同意できないだろうという主旨の反語表現と対になっているので、吸い殻を灰皿以外に捨ててはいけないことを言葉の後半の主張の根拠としていると考えられる。
これが根拠として成り立つには踏み消した吸い殻をそのまま捨てていくということが前提となっており、灰皿がないところで煙草の火を消す場合はその場に捨てていくのを当然と考えている、もしくは日常的に行なっていると推定される。

4 4bについて
反論ではなく、感情の発露であり、火を消さないへりくつを創出できなかったと推定される。また、喫煙し続けるための口実を全てつぶされたことを精神的苦痛に感じ、被害者意識を持ったと考えられる。

結論
ことごとく論破された具にもつかない反論(論と言うにも値しないが)からは、受動喫煙の防止という禁煙区画の目的を全く理解していないと考えられる。
また、全ての言動が禁煙指定に従う意思が全くないことを示している。実際、再三の指摘にもかかわらず喫煙を継続した。
このようなことから、当該人物の禁煙区画での喫煙は意図的なものであり、
この行為で生じた第三者副流煙喫煙は受動などという偶発的な印象をあたえる表現では不十分で被強制喫煙被害あり、
当該人物の行為は強制喫煙と呼ぶのが妥当だと考える。

2003年05月26日 23時02分14秒

指摘
駅ホームの禁煙区域で煙草を吸いながら歩いている人がいた。
1a「ここは禁煙だと思いますが」
1b「そうですか?」
禁煙の表示を再確認して、
2a「そうです」
2b「今消しますから」
消さずに歩き続ける。
3a「今すぐ消したらどうですか」
怒ったような口調と表情で恫喝のように
3b「ここで消せって言うのか!灰皿のあるところにいくんだよ!」
と足下を指さす。灰皿がないから床に吸い殻を捨てることになると暗に表現しているらしい。
4a「消してから灰皿に持っていけばいいじゃないですか」
4b「朝から***(正確に記憶していないが不愉快にあわされたというような内容***この馬鹿」・・・4
5a「どっちが馬鹿だ」
電車の発射時刻が迫っていたので打ち切り。

2003年05月26日 21時52分24秒

非常に複雑なページでさえ、息もつかせぬスピードで読み込みます。
appleの社員は肺活量が相当大きいようだ。
appleでは時間の進み方が違うという説も有力である。
# 3-4ヶ月が近日中ということから

表示できるかどうか心配で息を止めて待ってしまうということかもしれない。

2003年05月05日 15時39分23秒

nautilus on rh9
nautilusの設定項目からnautilus自体の使用をやめる選択肢がなくなった。
ユーザに設定変更させないというGNOME2/RedHatの思想統制が強化されたようだ。

2003年05月03日 22時19分05秒

wnn7 for rh9
あきらめてrh9の製品版を通販で買って、届いた日に
オムロンソフトからrh9用のアップデータが公開された。

というわけで、wnn7のライセンス2個とrichoフォント5書体のために6000円出したことになる。

2003年04月24日 23時12分36秒

dpkeyserv and rh9
RedHat9にしたら、Wnn7PersonalのdpkeyservがSegmentation faultを起こして起動しなくなった。
-vオプションでのバージョン表示はできるのだが。

RedHat9の箱売りではWnn7がバンドルされるということなので動くと期待したのだが甘かった。
バンドル版はバージョンが上がっているので、不具合が修正されたのだろうが、オムロンソフトのページには情報がない。

2003年04月21日 00時30分02秒

gtk2 does not support "over-the-spot"
gtk2ではpreedit-styleでover-the-spotは使えないらしい。
そんなわけで、mozilla-1.3-0_rh8_gtk2で、
user_pref("xim.input_style", "over-the-spot");
を指定しても無意味。
# それ以前の問題としてバイナリ配布のものはXIM無効でコンパイルされていて日本語入力ができないので、
mozilla/widget/src/gtk2/Makefileの#DEFINES += -DUSE_XIMという行の先頭の#をはずしてコンパイルしなおしたのだが。

gtk2を使う限り、日本語入力で左下に状態表示のウィンドウがでるのは避けられないようだ("root"にすればかわるのだろうが、入力中は別ウィンドウになるのだからよけい使いにくいはず)。
しかも、元ウィンドウにフォーカスすると必ず最前面にきてしまう。gnome2-gtk2の標準と思われる、クリックでウィンドウ選択(フォーカス)、フォーカス=最前面、の場合(ようするにwindowsと同じ挙動の場合)は問題ではないが、
マウスカーソルでフォーカス、フォーカスしても最前面には出さない(twmでこっちに慣れてしまった)、という設定では見苦しい。
左下の前面に別のウィンドウを置いてそれを見ながら、上の方の重なっていない部分で入力していると、
参照しているウィンドウの上に状態表示が出てじゃまになる。xwnmo(wnn7)の予測候補等も状態表示と同じ扱いのようなので、候補が多いとかなり鬱陶しい。

そもそも、GNOME2標準のウィンドウマネージャmetacityはフォーカスしても最前面には出さないモードは手抜きで、候補ウィンドウが消えたときに入力中だった(が最前面ではない)ウィンドウにフォーカスが戻らない場合があるので、どのみち使い物にならない。
# フォーカス=最前面を仮定しているのではないかと推定される。
メンテナもフォーカスしても最前面には出さないモードが使いたければsawfishにしろと言っているので、やる気もないようだ。
# windowsのような操作に限定して開発の手間を省いているのだろう。

2003年03月15日 13時18分26秒

xemacs + XIM (X11 Apple)
Xemacs-21.5.9ではX11にパッチを当てると、XIMにつながったが、文字化けした(ISO8859-1として扱われる)。
Xemace-21.4.12ではXIM(Kinput2)から日本語で入力できた。
21.5.9はβ版だからか。

2003年01月28日 02時02分01秒

2000
ついに、というか、ようやく、というか2000突破。

2003年01月26日 00時03分37秒

Xemacs(with-wnn) on Darwin
XIM有効でコンパイルしておいたつもりだったが、Kipnut2のXIM on/off を指定してもXIMを起動できなかったので、
--with-wnnでコンパイルし直した。
jserver直結で漢字入力できた。
--with-ximもつけたのだが、やはりXIM経由が使えない。

2003年01月20日 00時08分25秒

Kinput2-v3 on Darwin
コンパイルできたし、動いているようだ。
FreeWnnを入れたのでKinput2.confをWnn用に変更しただけ。

2003年01月19日 23時39分59秒

FreeWnn on Darwin
cppのところでconfigureが失敗するので、下記のパッチをあてたら、コンパイルできた。
Kinput2経由で使えたのでよいことにする。
XwnmoはXのソースなしでは難しそうなのであきらめた。
netinfoでユーザwnnを追加したが設定が不十分でセキュリティ上問題があるかもしれない。
/usr/local/lib/wnn/ja_JP/dicあたりのownerをいじらないとはまるかも。

*** configure.org Sun Jan 19 23:25:26 2003
--- configure Sun Jan 19 21:46:19 2003
***************
*** 697,702 ****
--- 697,709 ----
CCOPTIONS=""
CDEBUGFLAGS=-O
case $hosttype in
+ "Darwin")
+ CCOPTIONS=""
+ CDEBUGFLAGS="-O2"
+ if test -x /usr/bin/cpp; then
+ CPP=/usr/bin/cpp
+ fi
+ ;;
"Linux")
CCOPTIONS="-Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE"
CDEBUGFLAGS="-O2 -fno-strength-reduce"

2003年01月19日 23時35分45秒

磁石
磁石みたいにウィンドウの端がくっつく機能をmetacityで有効にする方法がわからない。
ソースを読んでフォーカス問題に対処するのも面倒なので、
sawfishを使うことにする。
(バイナリサイズも半分だし)
GNOMEもやめて、twmに戻るのもいいかも。

2003年01月16日 23時52分17秒

metacity
再現性が低いが、metacityでsloopyの場合に発生しやすい。
さらに、よく見ていると、候補ウィンドウが消える時に、かなりの確率で一瞬一番上にあるウィンドウにフォーカスしており、
まれに、もとのウィンドウにフォーカスがもどらないようである。
sawfishは、一番上にあるウィンドウにフォーカスしたりしない(あるいは私の肉眼で確認できるほど持続しない)。
metacityがfocus-on-clickかつraise-on-focusが標準で作られていることや、
sloopyモードはやる気がない(かのようなメンテナの発言があった)ことからの推測だが、
候補ウィンドウが消えたときの処理が、フォーカスウインドウと一番上のウィンドウが一致する前提で作られているのではないか。
ソースコードを見て検証しないといけないか。

2003年01月16日 23時20分31秒

Mozillaのせいではない。
Xemacsに入力中にも発生したので、Mozillaは悪くないようだ。
Xwnmoの出たり消えたりする予測候補ウィンドウと、Stay-on-Topが指定できるXawtvが存在すると、うまく扱えないのだろう。

2003年01月16日 22時13分55秒

GNOME2+Metacity+XWNMO+Mozilla+Xawtv (on RedHat8.0)
はまる。
MozillaはXIMの状態表示のフロートに凝っているため、over-the-spotにしないとフォーカスが移動してしまう。
XWNMO(Wnn7)の予測入力が有効だと、予測候補ウィンドウが出てくるが、
Metacity+Moziilaだと消えるときにフォーカスがランダムになる。
MozillaからでたフロートなのだからMozillaにォーカスを返すべきなのだが、
そういう情報が失われて、Metacityがでたらめにフォーカス先をきめるようだ。
Xawtvを使っていないと発生しないようにも見えるので、XawtvのStay-on-topが関係するのかも知れない。
日本語入力とは無関係に、Gnome-TerminalとXawtvとでフォーカスが激しく行き来するという現象もみられたし、
そもそもXawtvでStay-on-topを何度toggleしても、一番上にとどまらないので、
GNOME2かMetacityがStay-on-topをうまく処理できていないと思われる。

XWNMOとMozillaはフロートウィンドウに癖があるし、
Metacityはフォーカス処理に難があり、Xawtvはフォーカスをいじりたがる、
と、いかにも競合しそうな組合わせではある。
ただし、GNOME1+Sawfish+XWNMO+Xawtv(on Kondara2.1)では問題がなかった。

2003年01月15日 00時14分10秒

no-raise-on-click
twmのようなsloppy+no-raise-on-clickになれているような年寄り向けのmetacityパッチ
http://home.in.tum.de/~traykovs/metacity-2.4.1+classic_raise.diff.bz2

2003年01月11日 22時38分12秒

uninstall
win98seでoutlook express6を
アプリケーションの追加と削除を使ってアンインストールしたつもりだったのだが、
デスクトップにアイコンが残ったままだった。
MSの情報では95に関して、アイコンだけ残っていたら削除すれば良いように書いてあるのだが、
デスクトップアイコンだけでなく、すべて残っていて、全くアンインストールされていなかった。
唯一変わったのは、アプリケーションの追加と削除の選択肢から消えただけであった。

コンポーネントからオンラインサインアップを削除したのだが、
MSNだけ消されていなかった。
しかも、アンインストールの方法がなかった。

2002年11月02日 22時21分15秒

改善
さんざん文句を言ったが、ある程度は改善されたものも多い。
いままでのユーザーの声（苦情だろう）を反映したということだった。
半額切り替えの期限が9/30(手続きは10月中旬まで延長された）なのだと思っていたが、
9/30まではβ版だったようだ。
切り替えユーザの利用権は次の9/30まで変更されて、早く切り替えたらその分はおまけされるというので喜んだ人もいたが、
ベータテストにつきあわされただけで、駄目だしの手間を考えると、得だったかどうかは疑問。
もっとも、10/1になっても値段相応のサービスになっていない（はっきり言えば未完成）なので、
10/1からの使い始めたからといって、ベータテスターの苦行のおかげて快適に使えるわけではないので、
後発ユーザに比べて損だとも言えない。

2002年10月06日 17時43分15秒

メンテナンス予定はよくきかれる
Frequently Asked Questions
にメンテナンス予定が掲載されることがあるようだ。
メンテナンスの問い合わせはよくあるのだとは思うが、
告知ページを分かりやすいところに置く方がいいのではないか。
ちなみに、FAQには「お知らせ」というカテゴリがある。
さすがThink Different
考え違いを目指す会社だ。

2002年10月06日 17時29分20秒

こうしん
9/14/02 8:20am pst If you are having problems logging in to mail please try again in a few minutes. We're aware of the intermittent issue and are working on a resolution. No mail will be lost. Regards, Apple Support

になっているのだが、
一つ前にのせた日本語のはかわっていない。

2002年09月15日 22時57分08秒

ふるい
mac.com emailをご利用の皆様へ 9/12 9:30am JST - (9/11 5:30pm PST)
現在、一部のemail アカウントでメールの受信に問題が発生しております。現在障害を確認し対応を行っております。メールの受信を行う場合は、暫く時間をおいてから受信を行うようにお願いいたします。また一部のアカウントについて Mailbox 内のフォルダおよびメールが表示されないという現象が起きております。こちらにつきましては48時間以内に通常の状態に復旧する予定で対応を行っております。MailBox内のデータは存在しており、またその間に受信したメールは紛失することはございません。ご利用の皆様には大変ご迷惑をおかけいたしますがよろしくお願いいたします。

2002/09/13 11:26 (JST) に気が付いた。
.mac内のディスカッションボード(EMAIL)で掲載されているので、お金を払っていない人には分らないかも。

2002年09月13日 23時29分48秒

また
9/12/02 8:20am pst
If you are having problems logging in to mail please try again in a few minutes. We're aware of the intermittent issue and are working on a resolution. A small number of users may not see all their mail folders. They are still there and will be restored within 24 hours. No mail will be lost. Regards, Apple Support

持っていれば郵送するためにログオンする問題は数分に再度試みる。私達は断続的な問題に気づいてい、解像度に取込んでいる。少数のユーザーは彼らのメール・ホルダーすべてを見ないことができる。彼らはそこにまだあり、24 時間以内に復元される。郵便は失われない。点、Apple サポート
(The above is an automated translation provided by SYSTRAN.)

2002年09月13日 23時16分24秒

48時間
9/11/02 5:30pm pst If you are having problems logging in to mail please try again in a few minutes. We're aware of the intermittent issue and are working on a resolution. A small number of users may not see all their mail folders. They are still there and will be restored within 48 hours. No mail will be lost. Regards, Apple Support

気が付いたのは9:15am(JST)。
数分待ってから試したが読めない。
全てのフォルダーがみえない少数ユーザにあたるのだろう。
48時間メールが読めないかもしれないとは、さすが無保証.mac。

2002年09月12日 09時25分50秒

別を考えなさい
前回書いたように、凡人が広告を見て期待するのとはかけ離れたサービス内容なわけだが、
think different というのは、常識が通用しないということなのかもしれない。
念のため、架空の名探偵の名を騙る10.2自慢（雑誌の事前の記事より日本語対応が後退していることがか？）のツールで翻訳してみた（暫く前までは英日翻訳は選択可能だが翻訳不能だったのがいつのまにか直っていた）。

別を考えなさい

他のサービスに乗り換えろと言うことか。
Switchってそういうことか。
ちゃんと、整合がとれていたのだった。

2002年09月12日 00時40分55秒

どっとまっく
入らないとわからない注意事項。

1 英語ができない人はサポート困難
ディスカッションボードに書いたら一営業日でサポートしたい、といのは英語のみ。
日本語のディスカッションボードがあるが、こちらは、一日どころかほとんど回答なし。
（Buckupの不具合のお知らせ以外にサポートからの書き込みを見たことない）
英語のディスカッションボードではサポート担当者が頻繁に（当然まともに）回答しているそうだ。
確かに日本語でサポートがあるとは書いてない。
しかし、日本語表示にすると無条件に日本語ボードになるのに、そこは実はサポート無しというのは、紛らわしすぎる。
feedbackも入力フォームは日本語に翻訳されているが、意見や提案を日本語で書くと、submitしたあとで、english only だから書き直せといわれて、やり直しになる。

2 VirexはnetShieldではない。
IEやmozillaでダウロードするのをスキャンしはしない。
Mail.appは添付ファイルの展開はVirexにされるようだが。
Mail.appの場合でも展開しなければスキャンしないようだ。とりあえず、転送しても何もおこらない。
OSXの場合、データのアップデートは手動である。
OSXの場合、更新データは*.pkgとして月に一回でる。毎週更新するのが望ましいと書いてあるが、週一のデータはルート権限でファイルを置き換える以外の手段がないそうだ。
virex自体を上書きインストールしたら、virexのファイルがあるフォルダまでownerとpermitionを書き換えられた。/までownerが503になっていたのはひどすぎる。
日本語版はスキャン総量かメッセージ総量がある値をこえるとハングアップするようだ。もっとも、ダウンロード可能ではあるが、近日公開予定になっているので、非公開なのかもしれない。

3 Buckupは1.2よりまえはおかしい。
途中でキャンセルすると次から使えなくなることがあるらしい。

4 Homepage作成ツールはappleの見本のとおり
appleの提供する作成ツールは提供されるテンプレートをうめるだけ。
だけでできるのだが、だけしかできない。
自分で書いたhtml文書{をアップロードする|にリンクを張る}のはできない。
ここの作成ツールのほうがはるかにまし。
DOCTYPEはHTML3.2ということになるが、当然嘘。W3Cの検証はとおらない。

5 状況は現状のみ
サポートページでは状態がわかるというのは、英語で簡単な現状報告が表示されるだけ。例えば、2002/09/08 20:50(JST)には、

9/8/02 6:00am pst About 20% of email users will experience "Webmail unavailable" when attempting to log in to webmail. These users will also not be able to authenticate when connecting to mail.mac.com via an email client. We are aware of the problem and are working on a resolution. Regards, Apple Support

と表示されている。過去の障害履歴はみつからないので、どのくらいとまったことがあるのかは不明。メンテナンスの事前予告を見たという話は聞いたことがなく、事後報告しかなかったという話は多い。
例にもあるようにpstで動いているようで、過去のメールサーバのメンテナンスはpstで早朝だったそうだ。日本では22時から24時くらい。
20%というから5台はサーバがあると推測できる。アバウトなので、3台中1台(33%)かもしれないが。

基本的には.macはapple本社(USA)のサービスなので、日本語翻訳版ページがあるだけでも優遇されているそうだ（英語以外は日本語しかないらしい）。
契約も日本語に翻訳されているが裁判ざたになったらカリフォルニアだし。

日本語のディスカッションボードで”表示”のはずのところが、”侮ヲ”となっているのが象徴的である（二ヶ月放置されているらしい）。
英語もできないYellow Monkeyは侮られているのかと、自虐的な気分に浸るのも一興かもしれない。

2002年09月08日 23時11分29秒

ぼったくり可能契約
iToolsが有料の.macになったのだが、契約にはひどいことが書いてある。

お支払いという項目の最初の段落では
「事前通知でいつでも料金を変更でき、キャンセルしなければ同意したとみなす」
ということが書いてある。次の段落には、
「更新しない場合は更新日の５日前までに連絡しろ」
ということも書いてある。
ところが、事前通知の期間が全く記述されていないのである。

そうすると、更新日前の値上げが更新日の４日前に掲載されることもあり得、
この場合、値上げに同意せずキャンセルしようとしても間に合わないことになる。

新料金１兆円などということは現実にはないとは思うが、契約上はそのような値上げがあったとしても一度は更新を拒否できない可能性が残されている。

2002年07月20日 23時30分31秒

未完成品
さんざん銀行の対応に不満を書いたが、mozilla5の低評価は、未完成版をもとにして常用にたえないものをつくり正式版と称して配布した会社にも責任があるだろう。
mozillaが1.0に到達してこれからが本当の勝負だと思うが、
Netscape6が残した悪評のために、mozillaはバージョン5未満しか相手にしないというのが常識になってしまっていたら、
土俵に上がることすらできない事態になってしまうのではないか。

2002年07月13日 23時16分27秒

独善インターフェース
ソニーバンクがflush必須なのは独自のユーザーインタフェースを強制するためであるようだ。
あと、ベータ版ブラウザは使うなと言っているが、ブラウザが完成版かどうかは問題ではなく、まともなflushプラグインがあるかどうかが問題ではないのか。

2002年07月13日 23時05分12秒

mozilla5排斥
ほかにもNetscape6(mozilla5)を排除する銀行はあるようだ。
ソニーバンクにいたっては、flash5が必須。ソニーお得意のユーザーの便利さ無視の無意味激重ムービーもどきでも見せつけてくれるのだろうか。

とりあえず、CitiBankはNetscape6.1を推奨しており、アイワイバンク銀行ではチェックしていないようだ。

2002年07月11日 23時39分58秒

バージョンチェック
エムタウン支店の利用を考えたが、
利用環境の説明がwinとMacOS8-9にしか触れておらず、Netscape6は使えないと明記してある。
ためしに、ログオンしてみようとしたら、暗号化されて期待をもたせておいて
「このバージョンのブラウザは使用できません。」
という拒否ページを送ってきた。
まあ、winかmacのInternetExplorerかCommunicator4でないと閲覧できない方言htmlもどきを送りつけるのが
インターネットだという説を信じている人はいるようなので、しかたないのかもしれない。

そのわりに、lynxやw3mは拒否されなかったのはどういうことだろう。

Q&Aにはブラウザの制限は「ＳＳＬ128bit方式」を理由にあげているが、
実際の判定はSSLの対応ではなく、ブラウザ名とバージョンで行っているとしか思えない。
それも、mozilla5だけを排斥している。

あと、操作手順の説明を「体験版」と称しているのは、おわらいである。

本業も満足にできない会社の考えることは凡人の私にはついていけない。

2002年07月11日 22時52分49秒

mime
Subject: =?ISO-2022-JP?B?gmCCYoJigmCDaoOFgVuDWIFAg4qDaoOFgVuDQYOLgsyCqJJtgueCuQ==?=

こういうメールがきたのだが、SJISをmimeエンコードするときもISO-2022-JPでいいのだろうか。

2002年06月19日 20時48分51秒

備えあれば憂いなし
実際に弾圧されたのではなく、憂いがあるので備えただけ。

2002年06月16日 00時15分44秒

私のホームページへ | Technopolis-Marsのページへ | メイン | 今すぐ登録