TidBITS-J#497/13-Sep-99 TidBITS-J#497/13-Sep-99先週、Macintosh は米国陸軍より思いがけないサポーターを得ることとなっ た。彼らがホームページ用の Web サーバを Windows NT から WebSTAR を 搭載した Mac OS へと変更したのだ。また、Unisys 社が Web サイトオー ナーに GIF 形式の使用料を請求しているとの最近の論争では、Jerry Kindall が煙しか見えていないことを報告する。また今号では、QuickTime と Adobe GoLive のアップデートについて言及し、MacHack での例年の Bash Apple で Apple にフィードバックを送るための実践的な方法を見て みよう。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。TidBITS 日本語版 では翻訳に協力してくれる方を募集しています。詳しくは以下の URL を 参照してください。
<http://http://jp.tidbits.com/join_us.html>
今回の TidBITS のスポンサーは：
（翻訳：松岡 文昭 <mtokfmak@mxa.mesh.ne.jp>）
スピードの向上とバグ修正を行う GoLive のアップデート -- Adobe 社 は GoLive 4.0 のアップデートをリリースし、強力な Web 作成ツールの性 能向上とバグ修正を行っている。GoLive 4.0.1 では、全体的な体感速度の 向上に加え、Mac OS 8.6 でフォントが壊れる問題により生じていたクラッ シュ（ TidBITS-491 の“Font Manager Update 1.0”を参照）や、GoLive の PDF モジュールの使用に関連したクラッシュ等々、が修正されている。 もし既に GoLive 4.0 に Apple の Font Manager Update を使用済みなら、 アップデータのクラッシュを防ぐためにも、4.01 アップデータを使用する 前に GoLive の新しいコピーを再インストールすることをお勧めする。4.01 アップデータは 10 MB と重量級であり、GoLive 4.0 の登録ユーザーには 無償だ。 [JLC]
<http://www.adobe.com/prodindex/golive/>
<http://db.tidbits.com/getbits.acgi?tbart=05493>
<http://www.adobe.com/supportservice/custsupport/LIBRARY/5a62.htm>
QuickTime 4.03 アップデートでストリーミングのパフォーマンスを改善 -- Apple は QuickTime を 4.03 にアップデートした。QuickTime Player のお気に入りの引き出しに新しいコンテンツプロバイダーのリンクを追加 し、いくつかのバグを修正している。このメンテナンス用アップデートは、 ライブ・ストリーミングでのオーディオとビデオのシンクロを向上させ、 ストリーミングコンテンツ受信中にまれにクラッシュするバグを修正し、 Java 3.0.1 用の QuickTime の提供、そして QuickTime VR と Grolier Encyclopedia の相性問題を解決するものだ。既に QuickTime 4 をインス トールしているなら、QuickTime Updater プログラムを起動すれば Apple のサーバへと繋がり、アップデートされたコンポーネントをダウンロード できる。そうでなければ 380K の QuickTime インストーラをダウンロード すれば良い。 [JLC]
<http://www.apple.com/quicktime/>
<http://til.info.apple.com/techinfo.nsf/artnum/n31089>
TidBITS のサイズ変さらに関するフィードバック -- 我々は長い間 TidBITS を 30,000 文字以内に収めるよう努めてきた。内容を向上するた めの記事編集の観点から、我々は、サイズを減らすのではなく、今までの 厳格なサイズ制限を取り払うことを考えている。代わりに、毎号のサイズ の 目標を 30,000 文字としたい。もしある号が数千文字分長ければ、 可能な限りベストな記事を提供するため、必要と感じる部分のみを編集し ようと思おう。これによりいくつかの最後の数分での編集ミスを避けられ、 内容を向上させることができると考えるし、毎週発生している我々の不要 な作業も取り除けるのだ。
だが全ての変化にマイナス面はつきものだ。30,000 文字の制限は、旧式の メールゲートウェイを通過したり、古いメールプログラムで表示させるに は、適度な小ささなのだ。最近のほとんどのプログラムではもっと大きな メッセージを表示できるが、我々は決断する前にこの変化が起こしうるイ ンパクトを判断したいと思っている。何人かの人達は疑いもなく古いソフ トウェアを未だに使っている。私たちが知りたいのは、これらのプログラ ムが未だどれだけ残っており、どれだけ頻繁に使われているかだ。もしこ の変化であなたが影響を受けるなら、またはそれについての意見をお持ち なら、TidBITS Talk でのこのトピックのスレッドにポストをお願いした い。 [ACE]
<http://db.tidbits.com/getbits.acgi?tlkthrd=772>
by Adam C. Engst <ace@tidbits.com>
（翻訳：尾高 里華子 <rikako@pobox.com>）
Mac インターネットコミュニティが口を酸っぱくして言っていることに最 近ついに気がついた奴がいる。その正体とは、なんと米国陸軍だ。つまり こういう話だ。99 年 6 月 28 日、米陸軍のホームページに違法アクセス し、内容をいじった正体不明の侵入者がいたらしい。これは軍のような組 織が忌み嫌う行為であり、99 年 8 月 30 日、この件で「米陸軍の Web ページに悪意のある変更をした」として FBI がウィスコンシンの男性（19 歳）を逮捕した。
<http://www.army.mil/>
<http://www.dtic.mil/armylink/news/Sep1999/a19990901hacker.html>
米陸軍はこの侵入により軍のホームページのサーバを Windows NT ベース PC から StarNine Technologies 社製 WebSTAR の載った Power Macintosh G3 に変更することになった。陸軍ホームページの Web サイトアドミンで ある Christopher Unger 氏は、何がどのようになされたかについてや今後 の侵入を阻止するための対策については明かさなかったものの、「Web サ イトをより安全性の高いプラットフォームに移動させた」と述べた。W3C （World Wide Web Consortium）の情報をもとに Windows NT よりも優れた Mac OS を選択したとのことだった。Netcraft 社製ユーティリティ“What's that site running?”を利用して確認したところ、同陸軍のメインのサー バは現在 WebSTAR 4.0 をのせた Mac OS に置かれている。しかし、この ページからリンクが張ってあるその他のあまり目立たないサーバはおおむ ね Solaris の Netscape Enterprise か Windows NT の Microsoft IIS で 動いている。
<http://www.starnine.com/webstar/>
<http://www.netcraft.com/whats/?host=www.army.mil>
米陸軍がメインでないサーバもクラックされないように Mac OS に移すか どうかは判らないが、W3C の WWW Security FAQ には「もっとも安全な Web サイトは余計なものがついていない Web サーバを動かしている 余計なも のがついていない Macintosh である」という褒め言葉が出ている。また W3C は WebSTAR について次のように言及している。
「WebSTAR サーバはそれ自体でセキュリティを保つようになっており、 WebSTAR が Unix や Windows の競合するサーバと比べて安全性が高いとみ なされるのには理由がある。Macintosh はコマンドシェルを持っておらず、 かつリモートログインができなくなっているので、Mac が他のプラット フォームよりも本質的に安全性が高いと考えるのは道理にかなっている。 実際、WebSTAR およびその元であるシェアウェアの MacHTTP には安全性に 関する問題は浮上しておらず、今までのところこのこの考えは実証されて いる。」
<http://www.w3.org/Security/faq/wwwsf1.html#Q3>
<http://www.w3.org/Security/faq/wwwsf8.html#Q84>
この論理はほかの Mac OS 用 Web サーバ（たとえば Quid Pro Quo、 AppleShare IP の内蔵 Web server、NetPresenz、しいては Personal Web Sharing でさえ）についてもあてはまる。
<http://www.socialeng.com/>
<http://www.apple.com/appleshareip/>
<http://www.stairways.com/netpresenz/>
回想録 -- Macintosh インターネットコミュニティにとって Mac OS と Macintosh Web サーバの安全性はずっと前から知られていることであり、 この情報はニュースでも何でもない。 TidBITS-317 の記事「Macintosh Webセキュリティチャレンジの結果」で Chris Kilbourn 氏は賞金の 10,000 ドルを獲得するためにクラックを試みた人たちの手口をまとめた。 TidBITS-378 に掲載した「Crack A Mac の顛末記」では Joakim Jardenberg 氏と Christine Pamp 氏が第一回 Crack A Mac チャレンジが 成功のうちに終わった話をしてくれている。Geoff Duncan は TidBITS-385 の「セキュリティ・コンテスト考」で、二番煎じの Mac OS セキュリティ チャレンジがなぜやたらと開催されているのかについて取りあげた。さら には、 TidBITS-393 の「クラックされる!」の中で、第 2 回 Crack A Mac チャレンジで、セットアップをはるかに複雑にしたことによって生じたセ キュリティホール（これはとっくに解消されている）のためにクラックが 成功したという報告を行った。
<http://db.tidbits.com/getbits.acgi?tbart=01107>
<http://db.tidbits.com/getbits.acgi?tbart=02166>
<http://db.tidbits.com/getbits.acgi?tbart=02204>
<http://db.tidbits.com/getbits.acgi?tbart=04093>
もう一つ古いニュースは、Apple が Mac OS をインターネットサーバを動 かすのに適したオペレーティングシステムとして推進していないというこ とだ。数年前にバンドルされていた Apple Internet Server Solution が 姿を消して以来、Apple は Mac OS でインターネットサーバを動かすとい う現実をほとんど認識していない。Mac OS ベースのインターネットサーバ をなんら問題なく使用して Mac ユーザーが大勢いるというのに。今でも Apple 製のサーバはほとんど Unix である Mac OS X Server を動かしてい る。Unix ベースのインターネットサーバが悪いというわけでは決してない し、大容量のサイトには欠かせないものだ。Macintosh Web サーバ性能の 議論はほとんど無意味となっている。WebSTAR と Tenon Intersystems 社 製 WebTen はほとんどのサイトが必要とする性能をはるかに凌駕している ためだ。Web サイト、メールサーバ、FTP サーバの大多数にとっては、Mac OS と一般的に手に入る Mac OS ソフトウェアは親しみのある使いやすいソ リューションとなるもので、Unix や Windows NT のややこしさに悩まされ たりそのセキュリティ問題の心配も要らないのだ。
<http://www.tenon.com/products/webten/>
今後の展望としては、Apple が Mac OS をまじめにインターネットサーバ のプラットフォームに再度押し上げようとするとはとても思えない。企業 というところは技術的な姿勢を改めることなどほとんどないし、さらに大 切なことは、Apple が現在開発中の Mac OS X でそのインパクトが薄くな るようなことは一切したくないと考えていることだ。しかし、Mac OS X が インターネットクラッカーの標的になった時その安全性がどの程度のもの なのか知ることができるだろう。Unix のパワーと柔軟性を土台にした Mac OS X は様々な方面のユーザーにとってきっと魅力あるものだろが、クラッ カーをも魅了してしまわないことを願おう。
by Jerry Kindall <kindall@manual.com>
（翻訳：西村 尚 <hisashin@hotsync.co.jp>）
ある世界では、“Slashdot 効果”という言葉が、Slashdot で取り上げら れると Web サイトの得るトラフィックが実質的に増加することを表す。 Slashdot はギーク向けの Web サイトであり、この名前は Unix システム のルートディレクトリを表し、“/.”と記述できる。しかし、最近、別種 の Slashdot 効果があった。このサイトにたびたび訪れる一人のオタクが Unisys の Web サイトにあいまいな記述の文書を見つけたときだ。この文 書は、同社が GIF 画像を使う Web サイトに LZW 圧縮ライセンスを 5,000 ドルの定額料金で供与しようとしていることことを示していた。LZW また は Lempel-Ziv-Welch は、迅速で効果的な圧縮アルゴリズムで、モデム、 ディスクコントローラ、ハードディスク、圧縮ユーティリティ、テープド ライブに使われる。Unisys 社は LZW アルゴリズムに関する特許を所有し ている。GIF ファイル形式は LZW 圧縮を使うので、GIF ファイルを作成す るどんなソフトウェアも Unisys からのライセンスが必要とされる。最初 のライセンス騒動の記事については TidBITS-259 の“The End of the GIF-Giving Season”を参照のこと。
<http://www.slashdot.org/>
<http://corp2.unisys.com/LeadStory/lzw-license.html>
<http://db.tidbits.com/getbits.acgi?tbart=01670>
ただちに、フリーソフトウェア擁護者の多い Slashdot 住民は、この発表 をもっとも悪く解釈し、GIF 画像を使うあらゆるサイトから 5.000 ドルを 巻き上げる Unisys の策略だと読み替えた。対象のサイトは、おそらく夥 しい数のすべての Web サイトになろう。熱いスレッドがこのまがいものを 議論するために爆発し、Burn All GIF というサイトがこの極悪なやり方と 闘うために出現し、ウェブマスターたちに（今後決定される日に） Unisys 本社で暴露行動をして“やつらの GIF を焼き捨てろ”とあおったが、みな そうするつもりだった。
<http://slashdot.org/article.pl?sid=99/08/29/0722236&mode=thread>
<http://www.burnallgifs.org/>
たきつけるのはやめよう！ GIF の焼き捨ては煙ばっかりで火がつかな い。Unisys の発表をよく読んでみれば、“[も]し、ライセンスのないソフ トウェアディベロッパーまたはサービスから得た上述のいかなる種類の画 像でも、あなたの Web サイトで使用する場合は”ライセンスが必要である ということが明確になる。言い換えれば、GIF 作成に使用されるソフトウェ アのディベロッパーがライセンスを受けていれば、サイト自体にはライセ ンスはいらないのだ。Photoshop や DeBabelizer、ImageReady、 Fireworks、WebPainter など、人気の GIF ツールはすべて正しくライセン スを受けているので、ほとんどのユーザーへの影響はゼロだ。
実際には、Unisys がそう望んでも GIF ファイル形式それ自体に特許を主 張できない。あるいはもっと言えば、LZW 圧縮データを含むいかなるファ イル形式に対しても同様だ。この特許の範囲は LZW アルゴリズム だ。 つまりこの技術を使ってデータを圧縮するためにソフトウェア（あるいは 鉛筆と紙を手に勇敢な人）が行う一連の処理である。GIF ファイルまたは いかなる LZW 圧縮データも、LZW アルゴリズムそれ自体でなく、このアル ゴリズムの結果だけを包含する。ソフトウェアだけがソフトウェアの特許 を犯しうる。Unisys がサイトに LZW 圧縮ファイルがあるというだけでそ の Web サイトの管理者を告訴しようとしても、訴訟は棄却されるだろう。 現行の米国法では支持できないのだ。
Unisys の発表の私の解釈は、ライセンスを受けない LZW 技術を使う Web サイトに対して簡単に“合法化”させたいと望んでいるということだ。も し、あなたのサイトが Unisys から有効な LZW ライセンスを得ていない ツールによって作成された GIF ファイルを使っているなら、ライセンス料 を支払うことでどんな場合でも義務を果たすことになる。エンドユーザー が特許を犯すソフトウェアを使うことに対して責任を負うかどうかははっ きりしないが、この新ライセンスは、Web サーバー上で稼働し、リアルタ イムの株式グラフのような GIF ファイルを出力する無料で利用可能な C ライブラリを使う CGI プログラムをほぼ標的にしているのだと思う。
Unisys が LZW 特許を得た時点で、特許は発行日から 17 年間有効だった。 これは後に多国間 GATT（関税貿易一般協定）の一部として最初の出願日か ら 20 年間に変更された。つまり、Unisys の LZW 特許は 2003 年の半ば に失効するわけだ。旧法では、2002 年末付近で失効していたはずだ（最初 の出願と初めて認可された特許の間には 2 年の隔たりがあった）。面白い ことに、なぜ FSF サイトに GIF がないかを説明する Free Software Foundation のページによれば、IBM は Unisys とほぼ同時に LZW に関す る特許を出願し、特許局の局員が無関心だったので、IBM と Unisys 両社 が特許を受けた。IBM のものも Unisys のものとほぼ同時期に満期となる。 また、FSF ページには、この特許が LZW データを デコードする だけの ソフトウェアには適用されないので、あらゆる GIF 表示プログラムは自由 で障害がないという面白い話がある。このページは LZW と GIF にまつわ る特許の問題の有益な概略である。たとえ Richard Stallman 流の（われ われからすれば）若干こじつけの見方への傾向があるにしても。
<http://www.gnu.ai.mit.edu/philosophy/gif.html>
Unisys がすべての Web サイトを走査して誰が無許可で同社の特許技術を 使っているか調べるようなことは極めてありそうもない。単純にサイトが あまりに多数あるし、画像を調べるだけで GIF がどのプログラムで作成さ れたかを知るのは不可能である（ソフトウェアがそういった情報を提供す るコメントタグを故意に追加しなければ）。つまり、Web サイトが供与さ れたライセンスを得るいかなる要求も強制する方法はないわけだ。だから 落ち着こう。GIF 秘密警察があなたのドアをノックすることはないのだ。
しかし、多くの企業は内部にライセンス問題（つまり、非合法ソフトウェ ア）を発見し是正する専門の部署を持つ。そしてそういう会社のほとんど は今日 Web サイトを持ち、その多くは社内で開発したソフトウェアを使っ て構築される。これらの会社は単に安全でいるために Unisys に 5,000 ド ルを支払うことをいとわないかもしれない。わずか 100 のサイトがそうす れば、Unisys には実に 50 万ドルが入る。彼らはプレスリリースを打つだ けでいい。株価の上昇は一日仕事としては悪くない。結局、この騒動は 実際 それに貢献しているのだ。
[Jerry Kindall 氏は フリーランスのライター兼真面目な Macintosh ユー ザーのための週刊誌 MWJ の寄稿編集者であり、この記事は MWJ が初出で ある。もっと多くの洞察に満ちた Macintosh ニュースは、同誌の Web サ イトで無料で一切の義務のない MWJ 3 号分の試用購読を申し込もう。 Jerry の執筆に関して詳しくは彼の会社 Manual Labor 社のサイトを訪れ よう。]
<http://www.gcsf.com/>
<http://www.manual.com/>
by Adam C. Engst <ace@tidbits.com>
（翻訳：尾高 修一 <shu@pobox.com>）
（ ：亀岡 孝仁 <tkameoka@fujikura.co.jp>）
TidBITS に送られてくるメールから判断すると、多くの Macintosh ユー ザーは Mac OS や Apple の広告、Macintosh ハードウェアのスぺック、 ハードウェアの色揃えなど、Apple に関することおよそすべてについて、 なんとかして意見を Apple に伝えたいと思っているようだ。これは Apple にしてみればある意味ではありがたいことだともいえる。アイデアや意見 を惜し気もなく差し出したいと感じるほど、Macintosh ユーザーは献身的 なのだ。だが Apple は巨大企業でユーザーのフィードバックを吸い上げる 公式なルートはない。業界のムードはプレスや Apple 社員の知り合い、 Apple ディーラーの声、稀には宇宙からの発信など間接的な方法でじわり と Apple に染み込んでいくのだ。
問題の一部は Apple が単に大きすぎるということにある。コメントを送る ことができるメールアドレスがあったところで（最近の試みとしてあった <leadership@apple.com> は廃止になったようだ）、コメントを適切な部署 に送り届けるのは難しいし、その部署内にいる適切な個人に届くようにす るのはもっと難しい。Apple には従業員が多すぎ、しかも回転が早すぎて フィードバックを効果的に伝えることは至難の業だ。
Apple にはユーザーフィードバックを奨励したり取り扱う効果的なシステ ムが無いのではあるが、同社も Macintosh デベロッパーには耳を傾ける （ことも時にはある）。Apple's Worldwide Developers Conference （WWDC）はその一つの場を提供しているが、Apple が WWDC で目的として いるのはフィードバックを受け付けることよりもむしろ Apple テクノロ ジーを鼓吹することにあるのだ。だがフィードバックの方法はほかにもあ る。
Bash Apple -- かつてデベロッパー向けカンファレンスの MacHack で、 “Bash Apple”という名で呼ばれるようになったイベントがあった。伝説 によるとこういうことらしい。MacHack で Apple の馬鹿さ加減について文 句をたれていた一群のデベロッパーがいた。しばらくしてその中の一人、 Apple の新米社員だった Jordan Mattson 氏がこう言った。「あの、僕は Apple では無に等しい存在だけど、これを全部書き留めて社に帰ったら誰 かしかるべき人に伝えるようにするよ。何も約束はできないけれど。」で、 彼はその通りのことを実行したのだった。果たしてこの努力がどれだけ Apple に影響を及ぼしたのかは定かではない。だが結果はどうでもよく、 大切なのはデベロッパーたちが Apple 社員を相手に息をまく機会が与えら れ、気分を良くした彼らがその後夜通しで極度に無意味なハックを生み出 し、MacHack に参加していた他のデベロッパーの畏敬の念を集めたことに ある（今年のハックコンテストの詳細は、 TidBITS-488 の“The MacHack Hack Contest 1999”を参照されたい）。
<http://www.machack.com/>
<http://db.tidbits.com/getbits.acgi?tbart=05470>
デベロッパーたちは Apple 社員をつるし上げることが大いに気に入ったた め、翌年、そしてその翌年も同じことをした。このセッションは“Bash Apple”と名付けられ公式化され、数多くの Apple エンジニア（この多く は以前はデベロッパー側の立場にいた）の参加を見るようになった。 Jordan は MacHack の合言葉、「全部 Jordan が悪いんだ」として歴史に 残ることにさえなった。もちろん Apple の問題が実際に Jordan の責任 だったことはなかったのだが、彼は異論を挟まなかった。このセッション は苛立ったデベロッパーのガス抜きの場として機能する以外に、Apple 側 にも持ち帰って「ほら、俺一人が文句言ってるんじゃなくて、200 人のデ ベロッパーもぶうぶう言ってるんだ」という掩護射撃の材料になったのだ。
Apple Handshake 1999 -- 近年では、Bash Apple（今年は“Apple Handshake Session”というおぞましい名前になったが）は Apple 首脳が 会場にいる Apple 社員の力を借りながらデベロッパーの質問やクレームに 対応するというところにまで進化した。今年 6 月の MacHack（ TidBITS-487 の“MacHack: 究極の Macintosh イベント”参照）もその例 に漏れず、Apple の Mac OS エンジニアリング担当副社長、Steve Glass 氏が他の Apple 社員とともにほとんどの質問に答えた。たとえば、Apple が Appearance テーマをさらにリリースする予定はあるかという質問に、 Apple エバンジェリストの Tim Holmes 氏は、「今まで何度も言ったよう に、テーマには未来はありません。なし、おしまい、アウトです。」と言 い放って席に座った。その 1 秒後にはまた立ち上がって、今度はより注意 深く言葉を選んだ公式見解を述べた。「Apple 社には現在も将来において もテーマの新バージョンを提供するという、そのような計画はございませ んが、しかし今後計画に変更がある可能性がないとは必ずしも申し上げら れません。だらだらだら」などという具合だ。
<http://db.tidbits.com/getbits.acgi?tbart=05463>
セッションを通じて、時折重要な情報の断片が公にされたり強調されたり した。たとえば、Steve Glass 氏は Mac OS のコンポーネントを Mac OS のフルバージョンとは別に出荷することを徹底的に避けることにこだわっ た。たとえば Open Transport のバージョンを Mac OS とは別に出荷する ことはコンフィグレーションとテストの面で最悪の事態になり、かつ Apple がテストしたことのない組み合わせのコンポーネントを使っているユーザー にとって問題となりかねない。また、別の質問に答え、Tim Holmes 氏は Mac OS 9 は個別・共有の初期設定という意味で複数ユーザーをサポートす るものの、この機能は家庭やスモールオフィス向けのものであり多数のユー ザーを抱えた組織向きではないという重要な点を明らかにした。
だが、全体のところデベロッパーたちはセッションにあまり満足していな いような印象を受けた。Apple の副社長と話をしても、あまり具体的なこ とは聞き出せないままだったからだ。Steve Glass 氏は自分がチームを率 いている Mac OS 8.x に関してははっきりと答えることができたが、守備 範囲外のこと（Mac OS X、ハードウェア）や Apple 自身もまだ決めていな いことについてはお決まりの答弁になった。トレードオフ、資源の分配、 出荷時期、現在検討中などといった無意味な言葉が時折口をついて出てき たのだ。だが彼が言うべきだったことは? こうした無味乾燥な決まり文句 は実は 真実 であることが多いのだ。個々のコンポーネントのリリース とシステムの統一リリースにはトレードオフがある。Apple はエンジニア リングのための資源を未来のためのプロジェクトと System 7.x との下位 互換性維持のための両方に注意深く分配しなければならない。つまるとこ ろ、Steve Glass 氏はたとえば Steve Jobs 氏が Apple の復活のために魂 を売ったとか Java 2 を完全に無視したとか言われても、公式にはっきり と否定することができないのだ。これは全く彼のせいではない。仮に Steve Glass 氏が Apple が本当に Java 2 を無視する決定をしていたことを知っ ていても、それを MacHack で公表することはありえないのだ。
開発者課題トップ 10 -- 過去数年間プレスの人が 2 時間にわたる Q&A セッションのことを書くよりはずっとましだろうと心底信じて、MacHack の主催者側は開発者課題トップ 10 リストを作ることを決めて来た。この リストは集まった参加者の投票によるもので、Macintosh 開発者仲間が持っ ている課題を集約し優先付けしようとするものである。以下は少し手は加 えてあるが今年のリストであり、さらに可能な限り関係する TidBITS 記事 へのリンクも示してある。
1) MacsBug サポート：MacsBug デバッガは Macintosh 開発の重要ツール の一つである。開発者達は Apple 社がこのツールや似たような新製品にエ ンジニアリング資源を注ぎ込む事を必要としている。もしこれで何ができ るのか興味がある人は Geoff Duncan の MacsBug 三部作を見て欲しい。
<http://db.tidbits.com/getbits.acgi?tbser=1057>
2) 更なる安定性とより簡単なデバッグ：開発者達は Mac OS 上でのソフト ウェアについて信頼性の向上ともっともっと易しいデバッグ法を必要とし ている。Apple 社は System 7 以来安定性の向上についてそれなりの仕事 をしてきたが、更なる安定性は常に歓迎すべき事である。
3) Mac OS X の外見と感触：開発者達は Mac OS X が Unix ワークステー ションではなく Macintosh の様である事を必要としている。本件は我々も TidBITS-483 で“Mac OS X それとも Mac OS NeXT?”としてとりあげてい る。
<http://db.tidbits.com/getbits.acgi?tbart=05415>
4) ドキュメンテーションの改善：開発者達はテクニカルドキュメンテー ションがもっと早く、そしてもっと総括的で、正確で、手に入れやすい事 を必要としている。我々の“ドキュメンテーションの死”ではユーザドキュ メンテーションに焦点を当てていたが、この課題の多くは共通している。
<http://db.tidbits.com/getbits.acgi?tbart=04865>
5) もっとましなマウスとキーボード：開発者達は Mac の高級機はもっと ましな標準マウスとフルセットキーを備えたキーボードが必要であると確 信している。キーボードについては小さいことは必ずしも良いことではな い。驚嘆すべき事は、あの新型 Power Macintosh G4 ですら改良キーボー ドとマウスを含んでいない。
6) サポートのための機種差別化：開発者達は Mac がもっとわかりやすく マーキングされている事を必要としている、なぜならばサポートの人達は ユーザの機種を簡単に特定する事が必須だからである。私は会場でこの問 題を提起し開発者達も同じ事を思っていることを知り勇気づけられた。 TidBITS-485 の“Macintosh 製品名の衰退: 名は体を表す ”参照。
<http://db.tidbits.com/getbits.acgi?tbart=05436>
7) OS の拡張：Mac OS を計画外のところで拡張するために“パッチング” する機能は色々な、例えば身障者用アクセスを許す、理由で重要である。 開発者達は同様な機能を Mac OS X に必要としている。
8) Mac OS の整頓：開発者達は Mac OS がもっと整頓されればもっと良く なると確信している。OS からもう使われなくなっているコードを取り除く 事だけでも必要メモリや性能を改善し起動も速くできる。
9) Java：開発者達は Java についての明快な指針を必要としている。Java および Java 2 に関して Apple 社からのコミットメントが望まれる。
10) 非サポート開発ツールをオープンソース化する：多くの開発者が Apple 社がもはやサポートしていない開発ツール、例えば MPW の様な、に今でも 頼っている。この様なツールをオープンソースとして解放してやれば開発 者達は自分で不可欠と思うものについては保守と改良を加えていくことが 可能となる。
フォローアップ -- 今年の Bash Apple セッションに欠けていたものの 一つは昨年のTop 10 リストの再確認であった。もしリストの各課題に Apple 社がどの様に対応したか、そして開発者の問題意識も年と共にどの 様に変化していくのか見ることができるならば素晴らしいことであろう。 来年は、今年のリストが MacHack 2000 のリストとどう違うか個人的にも 必ず確かめたいと思う、それまでには種々の新型 Mac が、Mac OS X が、 そして Apple 社からは全く考えもつかない戦略の変更が見られるかもしれ ない。
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 