目次
前のページ
2016-08-03 カシオミニ 発売日(1972)
2016-08-09 宇宙からの初メール(1991)
2016-08-18 プリンタの不調
2016-08-19 ゴードン・ベル 誕生日(1934)
2016-08-25 Linuxの存在が明かされた日(1991)
2016-08-31 「人工知能」の生まれた日(1955)
2016-09-05 Gateway 2000 設立日 (1985)
2016-09-16 トヨタとセガとドリームキャスト
2016-09-27 Googleの誕生日
2016-10-05 GIF データの XMP Data チャンク構造
2016-10-10 CentOS 7 上の ndjbdns の落とし穴
2016-10-22 CentOS7 の nginx で https / http2 対応
2016-11-03 デザイン変えた
2016-11-27 セガ・サターン復活
2016-12-02 Windows で、二つのネットワークにまたがる VPN 設定を行う
2017-01-09 Android の cordova で file を扱う
2017-01-15 あの頃のインターネット
2017-02-01 些細な綴り間違い
2017-02-08 ボブ・バーマー 誕生日(1920)
2017-02-10 西和彦 誕生日(1956)
次のページ
今日はカシオミニが発売された日(1972)。
名前は有名ですが、もちろん僕は実機を使ったことも、ＣＭをリアルタイムに見たこともありません。
年がばれるけど、この世にはいたけど物心ついてない頃。
カシオミニは、ポケットに入るサイズの電卓です。
電卓というのは、「電子卓上計算機」の略です。卓上、つまりはデスクトップです。
その卓上計算機が、ポケットに入るサイズになるまでには激しい競争がありました。
「卓上」計算機になる前の話から始めましょう。
1950 年代、計算機と言えばタイガー計算機でした。
桁ごとにレバーが付いていて、その位置で 0～9 の数字を表します。
そして、クランクを回して歯車を動かすことで計算を行います。
足し算引き算はクランクを１回まわすだけ。
掛け算の場合、クランクを「かけたい数」だけ回します。
つまり、足し算を繰り返せば掛け算になる、という原理です。
ただ、大きな数をかけたいときにはこのままでは大変ですから、桁をずらすことで「筆算」と同じ原理で高速に計算できました。
割り算はもう少し複雑になりますが、おおむね掛け算の逆の考え方です。
1937年には、電動式のタイガー計算機も開発されていますが、高価で普及はもう少し後です。
電動式では、桁をずらす部分まで含め、自動的に掛け算・割り算を行ってくれました。
1950年代になると電動式も普及し始めますが、手動式でも高価なものだったので、一般的だったわけではありません。
コンピューターは「計算機」に自動制御機能を追加したものですから、電気式計算機もコンピューター以前からありました。
初期のものはリレー回路を使用していて、非常に巨大で、遅いものです。
それでも歯車式よりも高速で動作したため、特に膨大な計算が必要な組織で使用されていました。
この頃の計算機は、数値の入力も歯車式の計算機を模していました。
桁ごとに 0～9の数値を選ぶ、という方式です。10桁の入力がができるなら、10桁それぞれに 0～9 の数字が必要で、数字だけで 100個のキーが必要でした。
これを「フルキー方式」と呼びます。
カシオ計算機は、もともとはこの「リレー式計算機」を作成する企業でした。
まだ計算機と言えばタイガー計算機のような歯車式が中心で、リレー式計算機なんて作られていない頃のこと。
樫尾４兄弟の次男の発案で、リレー式の計算機を作り始め、1957年に「14-A」計算機が完成します。
カシオ計算機は、この機械の利益で作られた会社です。
使いやすさを考慮し、フルキー式ではなく、世界初の「テンキー式」を採用した計算機でした。
テンキー式とは…いうまでもなく、今の我々が知っている「計算機」の入力方法です。
10個のキーで 0～9 の数値を入力し、キーを押すごとに以前に入力した桁が上の桁に送られていきます。
表示に関しては、各桁ごとに 0～9 を示すランプがついていました。
まだ現在のような７セグ表示（いわゆるデジタル数字表示）はありませんし、それ以前につかわれた、数字の形の電極が重なるように入れてある「ニキシー管」も普及前です。
14-A は歯車などの機械部分を持たない「純電気式計算機」であり卓上計算機ではありません。
一見、机の上に置かれているように見えるのですが、その机こそが本体。上に載っているように見えるのは、入出力を行う操作盤です。
価格は 48万 5千円でした。
大学卒の初任給が１万円未満、あんぱん１個が12円の時代です。
＃当時の「大学卒」は、非常に限られたエリートだったことに留意。今の大卒と違って高給取り。
今の感覚でいえば、1000万円近い機械でしょうか。
1964年 7月、シャープが「電子卓上計算機」コンペット CS-10A を発売します。53万 5千円。
フルキー方式でしたが、カシオのものよりもずっと小さく、机の上に乗せることができました。
なによりも、リレーと違いトランジスタを使用していたため、高速でした。
カシオはまだリレー式を作っていたのですが、トランジスタ式の研究も開始し、いや応なく切り替えていく形になります。
ここにきて、電卓市場に乗り出してくる会社が相次ぎ、後に「電卓競争」と呼ばれる状態に突入します。
各社機能と安さを競うようになり、どんどんコストパフォーマンスが上がっていきました。
1966年 7月に、日本計算器販売の発売した Busicom 161 が、競争の中で一歩抜き出ます。
数値の記憶部分に高価なトランジスタを使うのではなく、安価なコアメモリを使うようにした製品でした。
値段は 29万 8千円。たった２年で、電卓の値段は半額近くまで下がったことになります。
同社は、製品名のほうが有名になったために、後に「ビジコン」と社名変更します。
この頃、電卓の機能競争は、購入する各社ごとに必要な計算を行いやすくする「アプリケーション」の競争に入っていきます。
銀行に納入するなら複利計算などがすぐできるように。設計事務所に納入するなら構造計算がすぐできるように。
レンズメーカーに納入するなら、光の屈折計算がすぐできるように…
これらをすべて、トランジスタの論理回路で実現していくのです。
値段は下げなくてはならない一方、このカスタマイズ作業が非常に大変で、電卓メーカーの収益を圧迫し始めていました。
また、トランジスタを使った回路ははんだ付け個所も非常におおく、工場での組み立てコストも悩みの種でした。
1969年、シャープが QT-8D を発売します。
世界初の、LSI によって論理回路を実現した電卓でした。
基本演算部分を集積回路にし、アプリケーション部分は別に作り込めるようにすることで、はんだ付けのコストを大幅に減らしています。
値段は 99,800円と、10万円以下を実現しました。
ビジコンも追随し、LSI を１つだけの「ワンチップ化」に成功。BUSICOM LE-120A。
これにより、電池駆動でポケットに入るサイズを実現します。89,800円。
とはいえ、これは小さすぎるため、アプリケーションの作り込みなどはできないものでした。
ビジコンの次の一手が、「アプリケーションを回路の組み合わせではなく、ソフトで実現する」という 141-PF でした。
値段は 159,800円と少し高めですが、計算結果をプリントアウトできる高級機種でした。
この 141-PF を作成する過程で、世界初の「1chip CPU」である i4004 が作られています。
こちらは過去に 4004の発売日 で書いているので、興味のある方はお読みください。
ところで、1960年代は「所得倍増計画」が実行された年代でもあります。
池田勇人内閣総理大臣の打ち出した政策で、10年間で国民の所得を倍増させる、という計画。
実際は所得は４倍に増えています。好景気の時代でした。
先に、1957年ごろの大学卒初任給が１万円未満、と書きましたが、1970年代頭には 4万 6千円ほどになっています。
ちなみに、あんぱんの値段も 12円から 40円に値上がりしています。
生活に余裕ができ、レジャーブームが起こったころでもあります。
特に、ボーリングは簡単な運動で誰でもでき、屋内なので天候にも左右されないなど、いいことづくめで大ブームを起こします。
カシオ計算機の中でもボーリングはブームでしたが、当時のボーリングはすべての計算を手で行います。
（今みたいな、自動計算はない時代ですから）
ボーリングの計算は結構複雑です。
ストライク（１回の投球で的をすべて倒す）、スペア（２回の投球で的をすべて倒す）を出すと、その後の２回、１回の投球の点数がボーナスとして加算されます。
さらに、この頃はブームですから上手な人もいて、ハンデなども考慮した計算が必要です。
ここで、カシオ４兄弟の四男が、「ボーリング用の電卓があれば売れるのではないか」と発案します。
ボーリングの点数は最大で300点なので、数ゲームやって集計しても４桁あれば十分。
その分値段を下げ、ポケットに入るサイズにして…
早速技術者が仮計算してみると、１万円を切る販売価格で作れそうです。
四男とその技術者の二人だけで、他の人には一切内緒で完成させてしまいました。
作成の過程で、８桁になると製造コストが上がるが、４桁と６桁では大して変わらないことが判明。
表示は６桁になります。
従来、１桁ごとに１つの蛍光表示管（広義の真空管の一種）を使っていたのを、６桁を封入した大きな蛍光表示管にすることでコストを下げます。
＃ただし、当初からそのように設計したというだけで、初期型には１桁ごとの普通のものが使われた。
６桁封入した管を特注すると、計画が他社にばれてしまう恐れがあったため。
表示は６桁ですが、６桁×６桁＝１２桁の掛け算性能を持ちます。
この際、上位６桁だけが表示され、下位６桁はボタンによる表示切替で見ることができました。
ボタンにはそれまで使われていたスイッチ（リードスイッチ）と違い、パネルスイッチを採用します。
パネルスイッチとは、基板に「途中が途切れた線」が作り込まれていて、スイッチ側の導電体を押し当てることで電気を流す仕組み。
今では当たり前に使われていますが、当時としては新しいコストダウン技術でした。
完成した電卓を重役会議で披露すると、兄弟の中での反応は上々。
しかし、部長クラスの重役になると「こんなおもちゃみたいなもの、売れるわけがない」という反応もあり、意見は分かれます。
当時の電卓は事務用品ですから、事務用品店の経路で販売されていました。
しかし、カシオミニは個人消費を狙った低価格商品です。
全く新しい流通網として、文房具屋に卸すネットワークを構築します。
そして、個人向けにテレビＣＭが作られます。
「答え１発！ カシオミニ！」
当初の予定を超え、12,800円になってしまったのですが、それでも当時は驚くほどの低価格。
カシオミニは大ヒットします。
生産が間に合わず、営業の仕事は客に謝ってまわること、と言われたほどでした。
月産10万台で、10か月後には100万台。
１年近くたっても生産量が下がらず売れ続けていたのですから、本当の大ヒット商品です。
海外にも多く輸出されていました。100万台のうち 20万台は海外輸出だったそうです。
当時の電卓は、高い計算力を持つ「兵器」の一種だという考え方で、業界では海外への輸出の自主規制が行われていました。
ただし、ここで定義される「電卓」とは、８桁以上の計算能力を持つもの。
カシオミニは、６桁しかないためこの規制も潜り抜け、自由に輸出できたのだそうです。
ここに「電卓戦争」の時代は終結します。
カシオミニはその後も改良が続けられ、まずは定価は据え置きで製造コストの削減・使い勝手の向上を、ついで値下げを行っていきます。
３年後には、4800円と５千円を切りました。
シリーズ累計では1000万台を超える売り上げ台数となったそうです。
同じテーマの日記(最近の一覧)
関連ページ
COMPET CS-10A 発表日(1964)【日記 19/03/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
1991年の今日、宇宙から初めてのメールが送られました。
メールと言っても、インターネットではなくてパソコン通信ですね。
1991年にはすでにインターネットメールはありますが、一般的に広まってはいなかったので。
具体的には、Apple が運営していた AppleLink というサービス上でのメールが送信されました。
1991年 8月 3日に、スペースシャトル・アトランティスが打ち上げられました。
ミッション番号は STS-43。
その中に「Mac in Space II」というプロジェクトがありました。
これ以前も、宇宙に DOS マシンを持って行ったりしたことはあったようです。
しかし、それらは特定の実験にコンピューターが必要になったから、などの理由。
このプロジェクトでは、もっと広範囲にコンピューターを…Mac を活用できないかを探るものでした。
乗員の健康管理にも使用されましたし、無重力化で使いやすいインターフェイスの実験も行われました。
メールの送信も、そうしたプロジェクトの一環だったのです。
実験には Macintosh Portable が使われました。
…Mac 好きの中でも、結構「珍品」扱いされる機種。
Portable は、妥協せずにデスクトップに見劣りしない性能を搭載し、キーボードやマウス代わりのトラックボールも内蔵したため、非常に大きくて重い機械でした。
元々 Mac は「電子文具」をコンセプトに開発されている側面があります。
初代から、小さなディスプレイは本体と一体型で、軽量でハンドルもついていたために持ち運べました。
このため、「持ち運びやすさ」でいえば、Portable よりも一体型 Mac のほうが上だったと言われることも多いです。
じゃぁ、なんで狭い宇宙船内に、そんなに大きな「Portable」を持ち込んだのか…というと、どうやら「トラックボール」が重要だったようです。
当時のマウスは、内部に球が入っていました。
球の入っている空間には余裕があり、球は「重力で下に引っ張られる」ことで接地していました。
また、球の動きは接触しているホイールで感知されますが、このホイールも重力で球と接していました。
つまり、マウスは宇宙空間では使えないのです。
そもそも、無重力空間では使いやすいインターフェイスも変わるかもしれません。
そこで、標準のトラックボール以外にも、３つの装置が用意されました。
・業務用ゲーム機などで使われる、大型の 2inch トラックボール
・操縦桿を改造して、上部に親指で操作できる小さなトラックボールを付けたもの
・光学式マウス
ちなみに、当時の光学式マウスは、今のものと違い、光を反射し、反射面に格子模様が印刷された専用のマウスパッドを必要とします。
＃この格子模様をわざとぐにゃぐにゃに歪めた「ジョーク製品」があって、まっすぐマウスを動かしても、カーソルはぐにゃぐにゃと動いた。
各種装置を使ってどれが使いやすいかを評価したはずなのですが、その評価については公開されていないようです。
さて、当時 Mac を対象としたパソコン通信を、Apple が運営していました。
サービス名は AppleLink 。そして、接続するための専用ソフトが AppleLink 。
パソコン通信は基本的に「文字だけ」の世界です。
文字で表示されるメニューを見て、文字でコマンドを送ると、文字でメッセージが送り返されてきます。
しかし、AppleLink では、Mac でファイル操作を行う Finder と同じ感覚で操作ができます。
接続後、メニューがアイコンで示され、アイコンをクリックすることでメニュー階層を辿れます。
そして、文章をクリックすると、画像や様々なフォントを含む「リッチテキスト」で表示されるのです。
もちろんメールも送れます。
宇宙から AppleLink に接続を行い、メールを送る、というのもプロジェクトの実験の一つでした。
8月 9日、宇宙の Macintosh Portable から地上に向けて、AppleLink のメールが送信されました。
送信したのは、Shannon Lucid と James C. Adamson の２名で、次のようなものでした。
Hello Earth! Greetings from the STS-43 Crew.
This is the first AppleLink from space.
Having a GREAT time, wish you were here,...send cryo and RCS!
Hasta la vista, baby,...we'll be back!
意訳：
こんにちわ、地球！ STS-43 の乗員からの挨拶です。
これは宇宙から初めての AppleLink です。
素晴らしいひと時、あなたがここにいてほしい、…cryo と RCS を送って！
地獄で会おうぜ、ベイビー、…すぐもどる！
これ、テストメッセージなので無茶苦茶。後半は冗談の連続です。
「あなたがここにいてほしい」はピンク・フロイドの大ヒットアルバムタイトル。
「地獄で会おうぜ、ベイビー、…すぐもどる！」は、映画「ターミネーター２」の印象的なセリフですね。
ミッション直前の 1991年 7月 3日に公開されたばかりでした。
＃映画では I'll be back! なのだけど、ここでは we'll としている。
冗談部分は正確な翻訳より、映画や曲名の邦題にあわせた。
cryo は cryogenics の意味で、極低温で貯蔵するものを意味します。
RCS は Reaction Control System で、姿勢制御のためのシステム。
スペースシャトルで極低温物質、RCS にも関連するものと言えば…液体酸素と液体水素燃料。
つまり、「酸素と燃料を送れ」って言ってるんですね。
「素晴らしいひと時」をもっと体験していたいから、酸素と燃料があれば滞在時間が伸ばせます。
2016.9.1 追記
コメント欄で教えていただきましたが、シャトルの RCS の燃料と酸化剤はヒドラジンと四酸化二窒素だそうです。
これらは常温で液体。混ぜただけで発火するために宇宙でも使いやすいのだとか。
液体酸素と液体水素を使っているのは、シャトルの発射時のみ使われる「メインエンジン」だけでした。
こちらは混ぜたうえで「着火」しないといけないので、火が燃えない宇宙では使いづらい。
…とすると cryo は何のことを言っているのだろう？
まぁ、内容を見てもノリ一発で書いている文章なので、あまり深く考えてないと思いますが。
このメールは簡単に送れたわけではなく、３回もリトライしてやっと届いたものなのだそうです。
その３回目も、メールは送信できたものネット接続を維持し続けることができませんでした。
つまり、この時点でのメール送信実験は、半分成功、半分失敗。
宇宙からのメッセージ送信方法として常用するのはまだ難しそうだ、という結果になります。
この実験から 19年後の 2010年 1月 22日、国際宇宙ステーションが、インターネットに直接接続されました。
これ以前にも、なんどか宇宙飛行士がネットにメッセージを送ったりしていました。
ただし、実際には地上にいる人間が送信を代行する形で運用されています。
それが、代行は不要で直接ネットに接続可能となったのです。
宇宙からインターネットへの、ダイレクト接続で最初に送信されたのは、twitter メッセージでした。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 おぉ、そうなんですね。ちゃんと調べずに書いてしまいました。ありがとうございます。 (2016-09-01 08:45:42)【vandy1】 本筋から逸れた話になりますが、シャトルのRCSの燃料と酸化剤はヒドラジンと四酸化二窒素ですね。 (2016-08-30 22:10:24) |
１週間ほど前に、Windows 10 anniversary update のお知らせが来たので早速入れてみた。
POPfile が動かなくなり、addUser すると戻る、というのは相変わらず。
まぁ、これはアップデートの度の恒例行事となった感があるので別にいい。
というか、そろそろ POPfile が対処する問題だと思うのだけど、新版は出ていないようだった。
それよりも、困ったのは、プリンタが不調になったことだった。
先に書いたのだけど、ちょうど決算期で帳票などの印刷が多かった。
プリンタが不調になり、何も印刷できなくなった。これは困る。
プリンタの不調で検索してみると、定番の答えが「一度プリンタを削除し、再度インストールしろ」だ。
やってみたけど不調は治らない。
問題切り分けのため、いろいろ試してみる。
現在、我が家のプリンタは Brother DDP-J557N だ。
これは、Google Cloud Print に対応している。
プリンタへの設定で、僕のグーグルアカウントと紐づける。
そして、Chrome から印刷する際に「Cloud Print」を選ぶ。
これで、Windows のドライバを使わずに印刷ができる。
問題なく出力された。プリンタはおかしくない。
Windows でテストページの印刷を試みてもプリンタは動かない。
プリンタキューのウィンドウを開いた状態で印刷すると、キューに一端入ったデータが、印刷完了したように消える。
しかし、実際にはプリンタは動かない。
キューが悪いのか…と、キューを使わない設定にしてみる。
すると、印刷した直後に、印刷したアプリごと落ちる。
どうやら、印刷する部分のどこかがおかしいようだ。
ははぁ、すると、キューに溜めた後に印刷しようとしたプロセスが落ちていて、キューからは受け取った、という扱いになっているのだな。
いろいろいじっていたら、プリンタドライバの設定画面にもテスト印刷があった。
試してみると、なんとこれが動く。
Windows のテスト印刷とは違う結果が出力される。
ノズルの目詰まりなどを確認するために、１ドットづつを制御する特殊な印刷を行っているようだ。
ということは、ドライバは悪くないのか。
うーん、Windows のプリンタドライバがどうなっているのか理解していないので、何が起こっているのかさっぱりわからん。
調べてみると、Windows のプリンタドライバは、カーネルプロセスとユーザープロセスの２つに分かれているようだった。
ユーザープロセスは、設定などのインターフェイス部分を請け負っている。
また、印刷したデータを受け取り、処理してキューに流し込む部分までを請け負っている。
カーネルプロセスは、キューからデータを受け取り、実際にプリンタまで送る部分を請け負っている。
なるほど、これでわかった。
おかしくなっているのはカーネルプロセスドライバだ。
独自のテスト印刷は動作したが、このときは細かな部分まで制御したいため、ユーザーモードからキューを介さずに直接印刷を行っているのだろう。
通常、Windows からプリンタを削除しても、ドライバまでは削除されない。
改めてプリンタをインストールすると、保存しておいたドライバが使われてしまう。
これだけでも、ドライバ登録情報などが壊れただけなら治ってしまう。
「ドライバからインストール」は初心者にはハードルが高いため、この対処方法が広まっているのだろう。
しかし、今はドライバが壊れているらしい、とわかってきたので、ドライバからインストールし直したい。
調べると、Brother のページに「ドライバ・アンインストーラ」があった。
これで、完全にドライバを消せるらしいので、いったん消去。
これでプリンタをインストールしたら…Windows10 に「Brother のプリンタドライバ」が入っているようだ。
機能は最低限だけどとりあえず動く、というもの。これを入れられてしまった。
最新の純正ドライバはダウンロードしてあるので、慌てて上書き。
これでプリンタは快調に動くようになった。
ところが、だ。これで終わりではなかった。
僕のマシンではプリンタが動くようになったが、妻が経理で使用しているノートパソコンから印刷ができない。
ブラザーのプリンタは去年の末に買ったもので、前回の経理作業の際にはなかった。
ノートパソコンはサブマシンで、特に印刷する必要もなかったのでドライバを入れていなかったのだ。
ドライバを入れたが、なぜか動かない。
こちらも、テスト印刷は出来る。
しかし、普通の文書を印刷すると、キューにたまったまま一向に送り出されない。
印刷を始めた瞬間、プリンタは紙を送って印字状態に入る。
しかし、そのままデータが送られてこないので、タイムアウトして紙を排出してしまう。
キューにたまったデータをキャンセルしても、今度は一向にキャンセルされない。
僕のマシンの不調とは様子が違うが、同じようにドライバのアンインストール・再インストールを行ってみる。
しかし直らない。
実は、以前もこうした状態になったことがあった。
その時は、家の中のネットワーク構成を変え、プリンタへの接続（WiFi接続している）電波が弱くなり、データを送るのに時間がかかりすぎていたのだった。
家のネットワークを見直す。スイッチングハブをリセットしてみる。
WiFi ステーションのファームウェアがアップデートしているのを見つけ、最新版にしてみる。
しかし、状況は改善しない。
ひとまず、必要な帳票を僕のマシンで印刷するが、経理マシンからしか印刷できないものもある。
妻がいろいろ調べていたら、原因は以前のプリンタのドライバがまだ入っていたことだった。
「プリンタ」は削除したのだけど、先に書いたようにドライバはまだ残っている。
ただ、ここでいうドライバは、単にハードディスクの上に残されているだけで、OS に対しては何もしないはずだし、できないはず。
（だって、プリンタを削除したことで、ドライバとしては動かなくなっているのだから）
でも、前のプリンタの純正ドライバは、プリンタドライバ以外にもいくつかのツールを残していっていた。
今時のスキャン一体型にはよくあることだけど、スキャンソフトとか入っていたのね。
これらの「なにか」が、ブラザーのドライバとコンフリクトを起こしていたようだ。
妻が以前のドライバを完全に消去したら、無事印刷できるようになった。
というわけで、今回の記事のまとめ。
プリンタが不調になったら、一度完全にドライバをアンインストールして入れ直してみよう。
該当機種以外のドライバでも、入っているプリンタドライバ関連は全部アンインストール。
最近は WiFi 接続のプリンタも多いけど、接続状態が悪いと印刷に時間がかかることもある。
今回は違ったのだけど、これも見直し項目に考えておいた方がいいかもしれない。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、ゴードン・ベルの誕生日(1934)。
PDP-11 の設計者にして、VAX の開発責任者。
そして、ハイ・パフォーマンス・コンピューティングを推進する「ゴードン・ベル賞」の提唱者です。
コンピューター業界を大きく変えた偉人。
PDP シリーズを開発した DEC 社は、もともと MIT の関係者が作った会社です。
MIT で開発された、TX-0 というコンピューターに将来性を感じ、量産するために設立された会社でした。
ゴードン・ベルも MIT の卒業生で、別の教授が設立した会社で働いていたのですが、引き抜かれて DEC の初期社員となりました。
当時は、コンピューターとは「専門のサービスマンしか触れない高価な機械」でした。
しかし PDP-1 は、購入したユーザーが自由に触ってよい機械でした。
ベルは、この PDP-1 の入出力システムを設計しています。
その後、PDP-1 の上位互換機である PDP-4 の設計を任され、PDP-5 にも参加、PDP-6 の設計も任されます。
しかし、これらの機械、ほとんど売れていません。
PDP-5 は初めての廉価機で、PDP-1 の 18bit とは互換性のない 12bit 、PDP-6 は DEC 初の大型コンピューターで、36bit でした。
その後も PDP シリーズは続くのですが、PDP-4 の後継機で初期の UNIX が作られた PDP-7 、PDP-5 の後継機で個人でも購入できるほど低価格となった PDP-8 あたりが有名です。
この後、ベルは DEC を辞め、カーネギー・メロン大学で計算機科学の講師となります。
そこで計算機のアーキテクチャなどを研究し、再び DEC に戻り、PDP-11 の開発を行います。
学術的な研究成果として作られた PDP-11 は、それまでのどんなコンピューターとも違っていました。
これまでのコンピューターは、技術的な都合で設計されていて、プログラマはその都合を察し、パズルのように最適なプログラムを組む能力が求められていました。
しかし、PDP-11 では「プログラマが使いやすい命令セット」が作られていたのです。
多数のレジスタ、直交性の高い命令、豊富なアドレッシングモード…
…これらの用語を説明すると長いので、知りたい人は PDP-11 を参考に設計された MC68000 の説明をお読みください。
ともかく、これはコンピューターのありようを変えてしまう大傑作でした。
この後は、PDP-11 のような設計が「良いもの」とされました。
先に書いた MC68000 だけでなく、PDP-11 を参考にしたコンピューターは数多くあります。
また、この後 UNIX は PDP-7 から PDP-11 に移植されます。
移植の際にはＣ言語が作成されるのですが、PDP-11 のアセンブラに「コンパイル」しやすいような言語設計を行ったため、Ｃ言語にはところどころに PDP-11 の影響が残る、とされています。
16bit の PDP-11 は、32bit に拡張されて、上位互換の VAX-11 となります。
この開発主任を務めたのもベルでした。
VAX-11 には、専用の OS として VMS が作られました。
しかし、PDP-11 用の UNIX もまた、VAX-11 に対応して普及しました。
VMS は非常に優れた OS だったのですが、VAX-11 「以外」でも使えた UNIX のほうが普及しました。
後に DEC は倒産し、部門ごとに解体され、別会社に吸収されます。
このときに、VMS を作成していた部門は Microsoft が吸収合併します。
ここで新たに作られたのが、VMS より一歩進んだ OS …アルファベットをそれぞれ一文字づつ進めて、コードネーム WNT でした。
後の Windows NT 、そして現在の Windows 10 のコア部分です。
ベルは DEC の副社長にまでなっていましたが、倒産前に退社しています。
その後マルチプロセッサシステムを作成する会社を設立し、このような並列コンピューター…「ハイ・パフォーマンス・コンピューティング」を推進すべく、ゴードン・ベル賞を設立します。
単に性能を競う、スーパーコンピューターのための賞ではありません。
「ハイパフォーマンス」の名前の示す通り、価格・性能比に優れたマシンや、それらを向上させる新アイディアなどに送られる賞となっています。
地球シミュレータや「京」、TUBAME2.0 など、日本の並列コンピューターもゴードン・ベル賞を受賞しています。
さらにその後、ベルはマイクロソフトの研究部門、マイクロソフト・リサーチの立ち上げから関わり、現在も名誉研究員となっています。
最後に、1992年10月に発売された雑誌に掲載された、ベルのインタビューから言葉を抜粋。
Twenty-five years from now...Computers will be exactly like telephones. They are probably going to be communicating all the time ... I would hope that by the year 2000 there is this big [networking] infrastructure, giving us arbitrary bandwidth on a pay-as-you-go basis.
意訳：
今から２５年後、コンピューターは電話のようになります。
それらは皆、常時接続で通信をしています。
2000年ごろには大きなネットワークインフラが整備されて、誰でもお金を払えば使えるようになることを願っています。
これ、あまりに的確で驚きました。
1992 年だと、まだインターネットブームの前。研究者なら使っていたけどね。
インターネットがブームになったのは 1995 年ごろで、google が有名になるのが 1999年ごろ。
ADSL によって家庭向けの「常時接続」サービスが始まるのが、日本では 1999年ごろ。
光ファイバによる常時接続は 2001年。
1992年から「25年後」は来年 2017 年なのですが、すでに電話とコンピューターの区別は曖昧となっています。
それらは皆、常時接続で通信をしています。
でも、同じインタビューでのもう一つの言葉を紹介しておかないと、フェアではないでしょうね。
Somebody once said, 'He's never wrong about the future, but he does tend to be wrong about how long it takes.'
意訳：
誰かがこういったんだ。
「彼の未来展望は決して間違えていない。だけど、時期については結構間違うね」
先の予測、時期までぴったり合っている、というのは偶然かもしれません。
同じテーマの日記(最近の一覧)
関連ページ
ケン・オルセン 誕生日(1926)【日記 17/02/20】
ケン・オルセン 誕生日(1926)【日記 17/02/20】
別年同日の日記
22年 vue-tweet-embed で表示していた Tweet が崩れる
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
この日をわざわざ取り上げるかどうか悩みました。
というのも、数日前に「Linuxの25周年の日」とする記事を読んでしまったから。
まぁ、幸い今日は他にめぼしい話題もないので（笑）、取り上げることにしました。
1991 年のこの日、Linus Torvalds は、minix のニュースグループに「minix のどこが好きですか？」という投稿をしました。
以下、意訳しましょう。
minix のどこが好きですか？
minix をお使いの皆さん、こんにちは。
私は、386(486) AT 互換機用の（フリーの）OS を作っています。
（GNU 製品のような大規模で専門的なものではなく、趣味にすぎません）
４月から作り始め、やっと動かせるような状態になってきたところです。
そこで、多くの人から、minix の好きな所、嫌いなところを教えてもらいたいと思っています。
というのも、私の OS は minix に似ているのです。
（ファイルシステムの構造など、全く同じです（そのほうが実用性があるため））
現在、bash(1.08) と gcc(1.40) が大体動いています。
数か月以内には、実用的に動くようになるでしょう。
なので、この後どのような機能を作るべきか、皆が何を欲しがっているか知りたいのです。
どんな意見でもありがたいです。でも、言われた通り作るとは約束できません。
Linus.(メールアドレス)
追伸.
minix のコードは一切使っていません。
マルチスレッドファイルシステムを持ちます。
移植性はありません。(386 のタスクスイッチなどを使っています）
そして、AT ハードディスク以外のサポートは一切ありません。僕が持ってませんから :-(
これに対し、すぐに反応した人が一人。
（ソースコードが）フリーであることに期待し、移植性がないというが Amiga への移植は困難そうか、と聞いています。
Linus は、移植性のなさがどのようなものか、詫びながら詳細を解説しています。
minix と違い、ハードウェアの機能をそのまま見せ、386 の機能に頼ってしまっている部分が多数あることを示す内容です。
この返信により、minix がハードウェアを隠蔽し、メモリ管理もややこしいことに対する「不満」が次々出されます。
どうやら、新 OS ではそれらの不満が解消されそうだ。期待している、なんなら手伝う、という内容です。
でも、このときはそれで終わり。
まだまだ「Linux」の姿は見えません。
Linux が本当に姿を現したのは、３週間ほどたった 9月17日のことです。
こちらは以前「Linux の初公開日」として書いています。是非合わせてお読みください。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、Artificial Intelligence という語句が生まれた日。
略して AI 。日本語では「人工知能」と訳されます。
Art というと美術とか芸術と訳されることが多いのだけど、原義は「技巧」。
Artificial となると「技術的に作り上げた」という意味になり、「人工」と訳されます。
Intelligence は知能、理解力、思考力、知性など、頭の良さを意味する言葉。
Artificial Intelligence で、「技術によって作り出された知性」の意味で、人工知能と訳されるわけです。
以前にも書いたことがありますが、ジョン・マッカーシーという方がいました。
MIT の教授で、学生に積極的にコンピューターを開放して、ハッカー文化を花開かせた功労者の一人です。
彼が助教授になったのは MIT ではなく、ダートマス大学です。1955年のことでした。
数学の博士号を持っており、知能を数学的に表現する研究をしています。
アメリカの大学は、夏休みが長いです。
また、アメリカの大学は企業と共同で研究を行うことも多いです。
マッカーシーは、1955年の夏休みに、IBM で仕事をしていました。
そして、そこで別の研究者に出会います。
当時ハーバード大学に在籍していた、マービン・ミンスキー。
彼は幅広い知識を持つ数学者で、マッカーシは彼と共に「考える機械」の可能性を語り合いました。
そして２人は、このような話し合いがもっと広くできないものかと考えます。
そこで、IBM で同様の研究をしている人を探し当てました。
ナサニエル・ロチェスター。
彼は MIT で Whrlwind I の設計に携わった後、IBM に入社して IBM 701 の主任設計士を務めています。
さらにその後、IBM でパターン認識やニューラルネットワークの研究を行っていました。
そしてもう１人、コンピューターの話をするなら当時この人は外せない、クロード・シャノンとも連絡を取ることに成功します。
夏休みの最後の８月３１日。マッカーシーは彼らに、来年の夏に自分の大学に来てほしい、という招待状を送ります。
この招待状の中で、マッカーシーは彼らが興味を持って研究している分野に対して名前を付けています。
その、新しい分野を示す語句が Artificial Intelligence、人工知能でした。
翌年の夏、マッカーシーは約束通りにダートマス大学で会議を行います。
ロックフェラー財団が、この会議を行うための費用 $7,000.- を出資しています。
会議は、１０人の研究者が集まり、多様なテーマについて１か月の間熱く語り合うものでした。
事前に挙げられた会議テーマは、コンピューター、自然言語処理、ニューラルネットワーク、計算理論、抽象化と想像力。
自然言語処理は、現在の機械翻訳などの元となっている技術です。
ニューラルネットワークは、ディープラーニングの元となる技術。
計算理論は、コンピューターを動かすための理論。
抽象化と想像力というのは、むしろ人間の問題。
「抽象化」というのは、例えば林檎を見て「りんご」という言葉で認識するような問題です。
そして、リンゴという言葉から、アップルパイのように全く違うものを連想できる。
一体人間はどのようにしてそれを成し遂げているのか？
哲学的な問いですが、人工知能の研究…「人間はどのように考えているのか」を明らかにしようとする研究では、これは一番大切なテーマです。
ここに挙げられたテーマは、扱い易そうなものから扱いにくいものまで、「人工知能」に関係しそうなことであればどんなものでも取り上げる、という姿勢です。
実際の会議の内容はよくわかりませんが、事前に用意されたテーマでなくても、自由な雰囲気で話し合いができたようです。
＃言い方は悪いのですが、ずっと雑談しているようなもの。
「会議」という名前が示すような固いものではなく、とにかく同好の士が一緒に生活しながら、寝ても覚めてもアイディアを語り合う場です。
この会議は大成功だったそうです。
これによって初期の人工知能研究は一気に進展します。
この会議の後、マッカーシーは MIT に移籍します。
その後、マービン・ミンスキーも合流するように MIT にやってきます。
マッカーシーが MIT の学生にコンピューターを開放したり、非常に高価な IBM 7094 を改造してマルチタスクにしてしまったり、マービン・ミンスキーと一緒に獲得した「研究費」である 300万ドルを好き勝手使い始めるのは、その後のこと。
結果的に、人工知能研究を強力に推進したことになるのですけど、日本ではなかなかいなそうなタイプです。
さて、人工知能は近年急速に進歩しています。
人間の命に直接かかわるような判断そのものにも使われ始めている。
今年８月の頭には、人工知能が、多くの医師が見抜けなかった難病を見抜き、治療法まで正しく示したために命が助かった、というニュースが伝えられました。
積極的に命に関与したかったわけではないけど、結果的に人の命を助けた人工知能です。
その一方で、自動車の自動運転技術なども開発されています。
上の話の１か月前…７月頭には、世界で最初の自動運転車による死亡事故が起きています。
こちらも、自動運転とはいえ運転手はハンドルを握らないといけない決まりでした。
にもかかわらず任せっきりにしていたが故の事故。ＡＩに全面的に責任があるわけではありませんが、結果的に人命を失ってしまった。
今後も、自動運転車などでは、ＡＩは責任を負えないので最終判断を人間ができるようにしたほうが良い、という意見と、人間にはミスがあるので究極的にはすべてをＡＩに任せた方が被害を最小に食い止められる、という意見の両方があります。
そして、同じことは積極的に「人を殺す」ための、戦闘兵器についても議論されています。
すでにイスラエル軍はロボット兵器を実戦配備し始めています。
まだ人間のサポートを必要としますが、最終目的は、自動的に敵を殺せるようにすること。
人を殺す判断を機械に任せてよいのか、という議論もあります。
一方で、機械だからこそ、確実に敵だと判断できるまでは、たとえ危険にさらされても攻撃しない、味方や非戦闘員への誤射を無くせるという期待もあります。
ロボット兵器により、戦争が今よりも「安全になる」という期待です。
ダートマス会議では、想像力のような人間側の問題も話し合われました。
そして、十分に人工知能が進化した今、やはり最後に残された問題は、道徳や倫理といった人間側の問題となっています。
自動運転車が事故を避けられない時、乗員１名の命を守ろうとしたら、３人の人をひき殺さないといけないとします。
でも、わざと壁に突っ込めば３人の命を助けられる。乗員は死亡しますが。
こうした状況をどう判断するか、究極の決断を迫られているのは、まもなく人工知能社会を迎える、我々全員なのです。
同じテーマの日記(最近の一覧)
別年同日の日記
15年 DOSBoxで日本語表示・JP106キーボード・UBASIC
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は Gateway 2000 の設立日 (1985)
一応まだブランドとしては残っているらしいのですが、覚えている人…というか、知っている人がどれくらいいるでしょうか？
パソコン自体には特に特徴がない、何の問題もなく使えるけど目立った特徴もない、というのが特徴。
通信販売中心で、送られてくる箱が非常に大きいのと、その箱が白黒の「牛柄」なのが強烈な印象でした。
一時期、パソコンと言えば Gateway 2000 という時代もありました。
それくらい売れていたのだけど… 強く輝いて去っていった、彗星のような存在です。
話としてはこれで終わりだよなぁ…
あとは Wikipedia に書いてある程度の情報しかない。
1985年にアイオワ州の農場の一角で創業して、DELL コンピューターのビジネスモデル（通信販売で、お客さんの注文を受けてから組み立てる）を真似して急成長します。
1989年に、牧場の写真と「アイオワからコンピューター？ (Computers from Iowa?) 」のキャッチコピーで広告を出して有名に。
それ以来、牛柄の箱をブランドイメージにして急成長します。
日本では、まだこの頃は NEC の PC-9801 シリーズが一人勝ちの状態。
もっとも、IBM が DOS/V で日本語を使えるようにして、徐々にシェアを伸ばしてはいました。
1993年に Windows 3.1 が発売され、OS が徐々に Windows に移行していくと、98 でないといけない理由も無くなります。
98 に比べ、性能が良いのに値段が安い PC/AT 互換機が急に売れ始める。
でも、この頃は「互換機」なのね。
IBM 製ではなく、有名メーカー製ですらなく、秋葉原のショップが組み上げたマシンとか、部品単位で購入して自分でくみ上げるとか、そうするのが普通だったし、特に有名な互換機メーカーもなかった。
この、保証やサポートも弱いし、知識がない人には難しそうな印象で PC/AT 互換機はまだ伸び悩んでいました。
1995 年、Windows 95 が発売されます。
それと同時期に、Gateway 2000 も日本法人を作り、日本での販売を開始します。
先に書いたように、秋葉原のショップマシンは、安いけれども保証が十分ではありませんでした。
Gateway 2000 は、同程度の値段で十分な保証付き。ただし、完全に自分でカスタマイズできるわけではなく、ある程度完成したマシンに、メモリ容量は HDD 容量を決定するだけの、セミカスタムです。
いや、それだからこそ、初心者にもわかりやすい構成でした。
Gateway 2000 のパソコンは非常に売れて、どこの会社にも牛柄の大きな箱が置いてあったものです。
…邪魔だから、たくさん買った際は「問題があった時に送り返す用に１つ置いといて、後は潰して捨てる」のが普通だったんじゃないかと思います。
僕のいた会社ではそうしていたし、人気漫画の『OL 進化論』にもそんなネタが出ていました。
同マンガではパソコンの話題とかあまり扱わないので、珍しかったがゆえに覚えています。
Gateway が Amiga の権利を買い取ったことがあります。
Amiga は熱狂的なファンのいる、独特な設計のマシンでした。
しかし、1994 年には設計者が死に、発売元の Comodor社も倒産しています。
その後、Amiga の権利は各社を転々とし…Gateway が購入するのです。
ファンは Gateway の開発力で、後継機を作ってくれることを望みました。
…が、そんな面白い展開にはならず。
子会社として Amiga 社を作って、一応開発はしていたようですが、とても商売にならないとみると、子会社に権利を売却して独立させています。
また、eMachines 社も合併していました。
こちらも、安くて性能のいいマシンを作っていた会社。しばらくはブランドが残っていましたが、現在無くなっています。
Gateway 2000 は、所詮は「DELL の真似」でした。
一時期は DELL 以上のシェアを持っていたのですが、結局 DELL に徐々にシェアを奪い返されます。
1998 年には、社名を Gateway に変更します。
もともと「2000年（未来）への懸け橋」という意味合いの社名でしたが、2000年はもう目の前でした。
しかし、その 2000 年にはアメリカ本社の経営が悪化。
翌 2001 年には経営規模を大幅に縮小します。
このときに日本からも撤退しているのですが、先に書いた eMachine を買収した際に、eMachine 社の日本での流通網を生かす形で再上陸しています。
しかし、努力もむなしく、2007 年には台湾の Acer に身売り。
現在も Gateway ブランドは残っているのですが、以前の勢いはすでにありません。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ドリームキャスト（セガのゲーム機）って、トヨタのお店で自動車の電子カタログに使われてたよね。
…っていうのは、当時のゲーム好きなら知っている話。
あれ、でもどうしてトヨタなんだろう？
セガとトヨタの間にどんな接点が？
って、今更急に気になって調べてみた。
半日程度で調べた話なので、間違いもあるかもしれない。
まず、自分がセガに在籍していたころ、携帯電話の普及黎明期だった。
あたらしい会社として「東京デジタルホン」が設立されて、セガ社員なら格安で入手できる機会があった。
そのため、当時のセガには東京デジタルホンユーザーが多かったはず。
…携帯電話の歴史話は非常に面白いのだけど、以前に書いたのでそちらを参照のこと。
また、携帯電話ブランド変遷史のまとめ方が面白い。
（僕のページはＰＨＳの話を含み、下のページはＰＨＳは含まない）
それはさておき、なんでセガ社内で東京デジタルホンを販売していたのか、というと、どうも親会社だった CSK が東京デジタルホンに一枚かんでいたらしい。
ここらへん、ざっと調べただけだと明確な情報がない。
CSK 社長だった大川功氏が個人的にかかわっていたというような話もあり、出資者としても CSK の名前は出てこないようだ。
ただ、非常に古い Internet Watch の記事があった。
1996 年 5月 20日のものだ。
携帯電話の特集で、東京デジタルホンのホームページ（WEBページ）の URL が書かれている。
しかし、ドメインは CSK だ。CSK の WEB サーバーに間借りする形で公式ページが始まっている。
（この URL を WaybackMachine で調べたが、一番古いアーカイブは翌年 1997年1月のもので、その内容は tdp.co.jp に引っ越した、というものだった）
今度はトヨタの方を見て行こう。
トヨタは言わずと知れた自動車メーカーだけど、自動車に関連するものとして、電電公社と一緒に「自動車電話」の研究を行っていた。
自動車電話のサービス開始は 1979年。
その後、電電公社がＮＴＴになり、電話事業が民間解放されると、日本高速通信を設立している。
高速道路沿いに電話線を埋設することで長距離電話をサービスする会社だ。
その後、日本高速通信は、自動車電話をサービスする「日本移動通信」を設立する。
後の携帯電話会社「ＩＤＯ」だ。もちろんトヨタも出資している。
でも、その後日本高速通信は赤字になり、消滅してしまう。
（KDD に吸収合併）
トヨタはＩＤＯにも出資しているのだけど、ライバルとなる東京デジタルホンの立ち上げにも協力し、出資している。
東京デジタルホンは日本高速通信のライバルだった長距離電話会社、日本テレコムが中心となって設立した会社だ。
なんでライバルに出資したのかは知らないけど、年表を見るとDoCoMo なんかにも出資している。
自動車をただの移動手段ではなく「移動オフィス」とする構想があり、競合する会社であっても「ライバル」ではなくて、「協力して市場を広げる仲間」だったのかもしれない。
トヨタと言えば自動車のイメージが強いのだけど、もともとは自動織機の会社だ。
そして、今では情報通信も重要な事業の柱になっている。
セガの親会社である CSK はコンピューターの会社だ。
でも、その社長である大川功氏は、コンピューターというよりは「情報通信」の世界で存在感を示した人だ。
まだ電卓が一般的でなく、タイガー計算機だって高価なので多くの人がソロバンをはじいていたころに、パンチカード集計機に出会って CSK（コンピューターサービス株式会社）を設立している。
コンピューターのメーカーではなくて、あくまでも「情報サービス」。
そして、情報は鮮度が重要なので、通信インフラの整備が必要、と考えが変わっていく。
同時に大川氏は、未来を担う存在としての子供に期待していた節がある。
Ｇ７のサミットに出席して「各国の子供の声を聴く会議を開きましょう」って提唱しちゃうし、個人資産から３５億円ほどを「子供たちのために」って寄付しちゃう人だからね。
その３５億の寄付は、子供にコンピューターとインターネットの教育を施すために使われた。
未来を担う子供たちが、情報通信によって国の垣根を超えて理解しあえれば、きっと世界は平和になる。
それが大川氏の思いだったようだ。
セガを子会社化したのは、セガの方から話を持ち掛けてきたからだ。
でも、コンピューターを子供の遊びとして提供する会社を最大限に生かし、子供になんとか通信ネットワークを使わせられないか、何度も試みているように思う。
メガドライブ、セガサターンには、どちらも純正周辺機器としてモデムが発売されている。
ドリームキャストに至っては、最初から内蔵している。
当時の速度の遅い回線ではアクションゲームなどには向かないし、ソフトをダウンロードさせようとしても時間がかかる。
結局全然普及せずに「早すぎた」ってネタにされている程度なのだけど、大川氏としては、ゲームよりも「環境」を提供したかったのではないだろうか。
実際、どれも「ゲーム」を主要な用途と据えながらも、情報サービスを提供しようとしている。
セガという会社の立場からゲームが注目されてしまうのだけど、情報サービスを提供したかったのだとすれば、低速な回線でもそれほど問題はなかったのだろう。
探しても資料が出てこないので記憶だけで書くのだけど、ドリームキャストよりも前に、三菱自動車が店頭に「マルチメディアカタログ」を置いていたと思うんだ。
当時僕は Macintosh を使っていて、雑誌も購読していた。
そして、そこにニュース記事が載っていたと思う。
このカタログ自体は、CD-ROM で作られ、Mac で再生できるもの。
QuickTime も使って動画とかも入れられている。
自動車ディーラーの店頭に置く、というのは珍しい試みなので話題になっていた。
でも、店頭に Mac を置こうというんじゃない。Mac は結構高いからね。
置かれたのは「ピピンアットマーク」だった。
ピピンアットマークについて説明すると長くなってしまうので、概略だけ書いておこう。
Apple 社が企画し、広く製造会社を求めたのだけど、バンダイだけがその計画に乗っかった「マルチメディア機」だ。
内部は廉価な Macintosh。
ゲーム機というには高価で、そもそもパソコンなのでゲーム向きに特化した機能はない。
ハードディスクを持たないためパソコンとしては使えず、インストールなしに CD-ROM から起動する専用ソフトしか動かないので、Mac の資産が活かせるわけでもない。
でも、Mac 用のソフトを「移植しやすい」。
あくまでも移植作業が必要。ピピンと Mac 両用のソフト、というのは作れるのだけど、Mac 用ソフトは動かない。
ちなみに、当時の Mac はビジネス機としては人気があったけど、家庭用のソフトとかゲームとかはあまりない。
…企画の時点から、いったい何に使えるのか疑問だらけの機械だったし、当の Apple が全然やる気がなかった。
バンダイはこの計画に乗りはしたが、おもちゃ屋なのでこんな複雑なものは作れない。
そこで、三菱電機に OEM 供給で生産を依頼した。初回生産分で５万台だったらしい。
そして、初回生産分を売り切ることができず、在庫の山を抱える。
「世界で一番売れなかったゲーム機」の異名を持つ。
三菱自動車の販売店にマルチメディアカタログを置く、というのは、おそらく三菱からの「救済措置」。
積極的にやりたかったわけではなくて、なんとか活用方法を見出した、という程度。
しかし、「マルチメディア」がまだ流行のキーワードだった時代、この話がちょっと注目されたのは事実なんだ。
これで状況が出そろった。
三菱自動車のカタログを、トヨタが「真似したい」と思ったのか、それとも在庫処分の方法をセガが「真似したい」と思ったのかはわからない。
（もっとも、トヨタとの提携は発売直後に行われている。まだ「在庫処分」ではなかったはずだ）
ともかく、トヨタとセガの間には「東京デジタルホン」を鍵としたつながりがあり、ドリームキャストを利用して、トヨタ車のカタログが作成されることになる。
ドリームキャストには情報通信機能が付いていて、トヨタは情報通信に力を入れていた。
単に車のカタログを表示しておしまい、ではなくて、トヨタの情報通信事業戦略上も一役買うようになっていたようだ。
ドリームキャストは「車のカタログを表示する端末」としての存在だけでなく、トヨタのお店で購入することができるようになっていた。
この際、購入できるのはおもちゃ屋さんで販売されていたものとは違う、トヨタ向けの特別版だ。
インターネット接続用のディスクがカスタマイズされていて、元トヨタ系の日本高速通信が吸収合併された KDD をプロバイダとして選び、トヨタのWEBページに簡単に接続できるようになっている。
となると、トヨタのお店にドリームキャストが置いてあったというのを、自動車の宣伝にゲーム機が使われたという「珍事」で片付けるのはちょっと違うようだ。
情報通信に力を入れるトヨタが、同じく情報通信を広めたい CSK と組み、その際に「子供でも使える情報通信端末」という理想的な機器としてドリームキャストが使われたのだろう。
もっとも、当時は多くの人がインターネットなんて知らない時代。
i-mode だって発売されてなくて、メールは一般的ではない。
そんな時代に「情報通信」よりも判り易い入り口として「自動車カタログ」だったんじゃないだろうか。
ゲーム機のポリゴンモデルで車を紹介する「珍しさ」で興味を引き、最終的にトヨタの WEB ページ（これも自動車カタログだ）を見てもらえれば、情報通信を広める目的は達成できたことになる。
実際うまくいったかどうかはともかくとして、戦略としては悪くないように思う。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
会社なのに誕生日、というのも不思議な言葉ですが、Google 社内で「創立日」とはべつに「誕生日」が決められているのだそうです。
googleドメインを取得したのが、1997年の 9月15日、google という会社が登記（創立）されたのが 1998年の 9月 4日。
ちなみに、ドメイン取得前から検索システム自体は存在していました。
1996年に開発開始で、そのころは BackRub と呼ばれていたそうです。
9月に節目があるのは、アメリカでの「新年度」が 9月に始まるからでしょうね。
何度も 9月に節目を迎え、どこが「誕生」かはよくわからないのも事実。
だけど、何かお祝いしたいために 27日が誕生日としているようです。
google については「創立日」にいろいろ書きましたので、そちらも併せてお読みください。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
仕事で GIF のデータチャンクなんて覗いている。
WEB の画像の多くが GIF だった時代なんかに、GIF をいじるプログラムは何度か作ったことがある。
画像データを直接いじったりするのはご免蒙りたいが、無駄なデータを削除したり、著作権表記のコメントを入れたりね。
今回はそれとも違う理由でデータを覗くプログラムを作っているのだけど、上手く動かないから直接バイナリエディタでファイルを開いたりしながらデバッグしていた。
動かなかったのは自分の勘違いだった。その話はいいんだ。
今日書きたいのは、Photoshop なんかで作った GIF ファイルには XMP というデータが含まれていて、このデータ構造が面白かった、ということ。
XMP は、画像に関する様々なデータを、人間に可読、かつコンピューター処理もしやすい形で、様々な画像フォーマット内に埋め込むための統一された方法。
Adobe が提唱していて、誰でも使ってよいらしいのだけど、Adobe 以外に使っている人がどれほどいるのかは不明。
多くの人にとっては画像に関するデータは EXIF があればいいよ…となりそうだけど、EXIF は JPEG と TIFF にしか埋め込めない。
XMP は、もっと多くの画像ファイルに埋め込めるようにしてある、という点で、一定の利点はある。
で、GIF にも埋め込めるわけだけど、その前に XMP データについてざっと解説しておこう。
まず、XMP は先に書いたように「人間に可読」だ。
テキストファイルになっている。
コンピューターにも処理しやすいように、XML と呼ばれる形式で書かれる。
もっと言えば、XML によって記述される、RDF と呼ばれる形式に従っているのだけど、そういう細かなことはこの際どうでもいい。
XML は < > の記号をやたらと使って書く。HTML の中身を見たことがある人ならわかると思うけど、親戚関係だ。
で、XMP は必ず「<?xpacket ～ ?>」という文字列で囲まれている。
画像ファイルをテキストとみなして検索し、この部分を取り出せばよい。画像ファイルの構造なんて知らなくても扱えるので、お手軽だ。
ところで、GIF ファイルには、コメントとして文字列を埋め込む機能がある。
なーんだ、簡単。じゃぁ、XMP もコメントとして書けばいいわけだ。
…ところが、そうはいかない。
GIF は内部でチャンク（データのまとまり）構造を取っているのだけど、基本的に次のような構造なのだ。
・何を示すチャンクであるかの ID 1バイト
・そのチャンクに必要なデータ 数バイト（ID ごとに構造が決まっている）
さらに、必要に応じてチャンク内のブロックが作られる。
ブロックの数は任意だ。なくてもいいし、何個続いてもかまわない。
・データ長 1バイト
・データ長の長さのデータ
データ長が 0 の時、ブロックはそれで終わりだということを意味する。
逆にいえば、0 にならなければ、いくらでもブロックを続けてよい。
ここで重要なのは、データ長が1バイトだということで、データの長さは最大 255バイトとなってしまう。
先に GIF ファイルにはコメントを埋め込める、と書いたのだけど、255 文字で一区切りだ。
それ以上のコメントが入れられないわけではなくて、内部で複数のブロックに区切って格納される。
でも、先に書いたように、XMP はファイル構造を知らないでも取り出せるテキストとして埋め込まれる。
それでは GIF ファイルのコメントとして適した形にならない。
ここでちょっと工夫が必要になるわけだ。
さて、GIF における XMP の構造。ちょっとした Hack だ。
まず、「データ長1バイト」なんて気にせず、データ長の部分からいきなりテキストファイルを書き始めてしまう。
XMP は結構長くて、普通は 255 文字なんかに収まらないけど、最後まで一気に書ききる。
XMP の先頭は < なので、ASCII コードに従ってデータの長さは 60 ということになる。
GIF フォーマットを読むつもりで見ると、そこまでテキストを読み飛ばして…次の「文字」の文字コードが、次のブロックの長さ、ということになる。
一応、可読テキストなので ASCII コードの「 0 」、いわゆる null 文字は入らない。
だから、チャンクが終了してしまうことはなく、テキストはちゃんとチャンク内に格納されていることになる。
でも、こうやって読み飛ばしていくだけでは、いつかテキストの終わりを飛び越えてしまうだろう。
もちろん、その通り。
XMP テキストは、<?xpacket ～ ?> で囲まれている、と書いたのを思い出してほしい。
最初と、最後にこの文字列が付いている。
逆にいえば、XMP テキストを取り出したい人にとって、その外側にあるデータは関係がない。
そこで、GIF ファイルの XMP データは、テキストの直後に 255 から 0 に至る、1つづつ数の減る 256 byte のデータが埋め込まれている。
GIF ファイルのつもりで読んでいると、いつか XMP テキストの終わり飛び越し、このデータの中に着地する。
データは、1バイト進むたびに、1数値が減っている。
だから、その数値の分だけ先に進むと、どこから始めたとしても、必ず同じ場所にたどり着くことになる。
そして、その数値は「0」だ。
先に書いた通り、データ長が 0 の時は、チャンクの終了を意味している。
そのため、XMP を格納したチャンクは、ここで終わる。
先に書いたように、僕のプログラムミスで GIF ファイルを覗くプログラムがうまく動かなかった。
デバッグのためにバイナリエディタで直接観察したら、こんな構造のデータがあった。
255byte でブロックを作る、という規則を無視して入れられた、とても長いテキストデータ。
最初は、こいつが悪さをしていて自分のプログラムが動かないのではないかと疑った。
でも、他のプログラムは正しく画像を出しているのだから、問題はないはず。
次に考えたのは、XMP 用に特別な構造の追加仕様があって、僕のプログラムがそれに対応できていない、ということ。
でも、これも違う。後から追加するデータ仕様が、それ以前のプログラムの動作と非互換なわけがない。
そう思って冷静に動作を考えたら、上に書いたような巧妙な構造が見えてきた。
この構造の欠点は、256byte も無駄なデータを詰め込んでいることだ。
でも、そもそも XMP 自体が、画像だけを見たい人にとっては「無駄なデータ」だ。
データを入れたい人にとっては必要があるから入れるのであって、その場合は 256byte くらいは誤差範囲だろう。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
CentOS 7 のサーバーを構築しているのだけど、djbdns に「落とし穴」があったので記して置く。
djbdns は DNS サーバー。
DNS サーバーのプログラムとしては BIND が有名なのだけど、前世紀からセキュリティホールが多すぎることが問題となっていた。
djb こと「ダニエル・ジュリアス・バーンスタイン」がそれに腹を立て（？）、セキュリティ問題が出ない DNS として作ったのが djbdns だ。
BIND はその後、一度全面的に作り直されて「BIND 9」となった。
セキュリティ問題は多少は改善したらしいのだけど、根本的にはやはり変わっておらず、セキュリティアップデートを繰り返している。
つい先日も、非常に重大な脆弱性が見つかっている。
djbdns は、2001 年に公開されてから、セキュリティパッチが当たったのは 2009 年の1度だけ。
実のところ、BIND に限らず、DNS サーバーはセキュリティアップデートが多いソフトの一つだろう。
というのも、DNS の仕組みそのものがあまり良い設計ではなかったから。
インターネットに悪人はいない、という思想で設計されてしまった。
実際、悪人がいなければうまく動くし、現在のインターネットは DNS なしには考えられない。
でも時々、ソフトではなく、DNS の規格自体にセキュリティ問題が見つかる。
こうなると、BIND に限らず、DNS サーバープログラムが軒並みアップデートしたりする。
でも、この場合も djbdns だけは大丈夫、ということが多い。
最初から規格を信じていないし、自分が作ったプログラムすら信用しない、という姿勢で作られているため、そもそも問題が出にくいし、問題が出た場合でも影響が非常に少なく、セキュリティホールになりにくい。
…と、ここまで書くといいことづくめのようだ。
でも、そんなにいいものなら皆が使うだろう。
実際には、多くのサーバー管理者が敬遠して使わないような、ひどい部分のあるソフトなのだ。
セキュリティが強固な代償として、プログラムをインストールし、設定するのが非常に厄介だ。
たとえば、どんなサーバープログラムでも、そのサーバーの「設定」を行うファイルを持つものなのだけど、ファイルの読み込みって実はセキュリティホールになりやすい。
そこで、設定ファイルを読み込むプログラムと、実際に動作するプログラムが分離している。
そして、このプログラム自体が、問題の出やすい「設定ファイルの文法解釈」を行わないようになっている。
具体的にいうと、ファイル名がそのまま設定項目で、ファイル内は1行だけ、というのが基本。
設定のためのディレクトリの中に、多数のファイルが入れられた状態となる。
管理する立場になると、設定項目を一覧することもままならない状態。
プログラムをサーバーとして動作させるときは、万が一停止した場合に備えた仕組みが必要になるのだけど、その仕組みも別のプログラムになっている。
DNS の「問い合わせ」に応対するプログラムと、「解決」を行うプログラムも別になっている。
そして、万が一脆弱性により「乗っ取り」が起こった場合でも問題が起きないように、これらのプログラムの権限は分離している。
UNIX では権限はユーザーに付随するものなので、サーバーを動かすためだけに、複数のユーザーを登録する必要がある。
BIND より信頼のおけるものだとしても、この複雑至極なインストール方法と設定方法が嫌われていて、あまり使われないソフトの一つだ。
＃あと、勘違いも多い。
最後のアップデートが 2009年、と聞くと、開発が停止していてセキュリティホールだらけなんじゃないか、と思う人が多いようだ。
上に書いたように、セキュリティチェックは頻繁に行われていて、アップデートがないのは何も問題がないから。
開発はもちろん継続していて、報告があればいつでもアップデートされる。
さて、そんな高性能だけどインストールと設定が厄介な djbdns が、コマンド一発でインストールされ、使えるとしたらどうだろう？
CentOS 7 には、djbdns の改良版である n-djbdns (New djbdns）が提供されている。
yum install ndjbdns でインストールできる。
改良版と書いたけど、改良かどうかはわからない。
動作権限はあまり細かく分かれていないので、万が一問題が生じた際の保証はない。
もっとも、「万が一のために」動作権限が分離されているのだけど、過去にそういう万が一が報告された例はないから、これはこれでいいかもしれない。
設定ファイルも、ごく普通のものになったので設定しやすい。
先に書いたように、ファイルの読み込みはセキュリティホールになりやすいのだけど、どうも n-djbdns では、設定ファイルを読み込むプログラムだけを改良して、その部分を使いやすくしたようだ。
これは設定ファイルの読み込みだけなので、サーバーのセキュリティ問題は出にくそうだ。
とはいえ、「文法解釈」という、複雑で問題が出やすいものを導入してしまったのは事実で、djbdns よりはセキュリティの強度が落ちるかもしれない。
先に書いた、サーバーとして動作させるための仕組みは、djb が専用に作ったものではなく、CentOS7 が使用する systemd に任せる形になった。
systemd 自体が複雑すぎて、セキュリティホールの温床になりそうだ、という批判はあるのだけど、それはまた別問題。
まぁ、複雑怪奇で使われにくい djbdns を、使いやすいようにうまくまとめてある印象。
しかし、最初に書いたように、一つ落とし穴があった。
axfrdns の設定方法がわからない。
DNS サーバーは、普通２台を一組にして設定する。
DNS は非常に重要なものなので、万が一片方が停止しても、もう片方で運用を続けられるようにだ。
このとき、メインにデータを設定すると、もう１台に自動的にデータが転送される。
でも、データを転送したいのであれば、ファイル転送の仕組みを使えばよい。
UNIX には scp という、非常に優れたファイル転送コマンドがあるから、それを使えば解決だ。
…と、djbdns では考えている。
BIND では、このために専用の仕組みを用意していて、「ゾーン転送」と呼ばれる動作が行われる。
djbdns と BIND を混ぜて使うような特殊な状況だと、ゾーン転送にも対応しないといけない。
このための仕組みが、axfrdns だ。なくても良い存在だ。
でも、僕はまさに bind との連携をしないとならない、という事情があった。
その axfrdns が使えない。
よくわからないよ？ と思ってネットで情報を探したのだけど、そもそも djbdns で axfrdns を使っている人も少ない状態。
ましてや、まだそれほど普及していない n-djbdns では設定例が全く見つからない。
そして見つけたのが 2013 年の、n-djbdns 開発の掲示板ログ。
ここで、やはり axfrdns の設定ができない、という質問に対し、n-djbdns の作者（djbdns からの改良者）が、axfrdns を自身が使っていないため、機能を理解していないと認めている。
ただ、認めて終わりではなくて、要望を受けて改良しているんだ。
設定がちゃんとできるようになり、起動も可能となった、ようだ。
でも、この時点では CentOS 6 の時代なのね。
まだ systemd はなくて、別の方法で起動を行う設定ファイルが紹介されている。
さらに、axfrdns の設定で「本当に」必要なことが、この方法では満たせない、という報告がある。
起動できなかったのが起動は出来るようになった。でも、それでは役立たないのだ。
こちらについては「将来のバージョンで対応するかもしれない」という形で終わっている。
CentOS 7 の起動スクリプトは、この掲示板で示された CentOS 6 用のものを systemd に移植するような形になっていた。
ただ、CentOS 7 特有の問題により、何か違う問題が起きているようだ。
というのも、起動を試みても失敗するから。
なにか専用の設定を行えば起動できるのかもしれないけど、起動したとしても、先に書いたように「動くけど役立たたない」可能性が高い。
先に書いたように、axfrdns は、djbdns にとって必須の機能ではない。むしろ使わないほうが良いくらいだ。
セキュリティホールの多い BIND ではなく、djbdns を気軽に使いたい、という人にとっては、CentOS 7 で yum 一発でインストールできるのは良いことだと思う。
axfrdns 相当の機能が必要な場合は、残念だけど BIND を使うか、素の djbdns を自分でインストールすることになるようだ。
僕は以前のサーバーで、素の djbdns を使っていたので、後者を選ぼうと思う。
関連ページ
CentOS7 の nginx で https / http2 対応【日記 16/10/22】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
すこしまえに、CentOS7 の ndjbdns を使うと一部機能が使えない、という話を書いた。
今度は nginx の同様な話。
CentOS 7 では、nginx の yum パッケージがあるのだけど、これで http2 を使おうと思っても使えない。
じゃぁ、nginx を作り直せばいいんだな…と思って自分で構築しても、やっぱり使えない。
nginx はエラーを出さないが、ただ http2 が使えない。
エラーが出ないので原因に気付くのに時間がかかった。
結論から言えば、CentOS 7 の OpenSSL のバージョンが古い
1.0.1i 以降の OpenSSL がないと http2 を使えないのだけど、CentOS 7 のバージョンは 1.0.1e だ。
ちなみに、この日記執筆時点の最新版は 1.0.2j 。
nginx のソースと、OpenSSL 1.0.2j のソースを /usr/local/src に置き、nginx の configure に以下を加える。
--with-openssl=/usr/local/src/openssl-1.0.2j/
--with-http_ssl_module
--with-http_v2_module
これで CentOS 7 の nginx でも http2 通信ができるようになる。
2018.11.16 追記
8月に、WEBで使用される新しい暗号技術、TLS 1.3 の策定が完了、公開されました。
これに伴い、各種ブラウザでも TLS 1.3 の実装が行われています。
この記事は、TLS 1.2 時代のもので、次第に古くなる可能性があります。
とはいえ、古いブラウザのために TLS 1.2 はまだ残されますし、現状では下の設定でもセキュリティ評価は A+ （最高ランク）になります。
追記時点での、OpenSSL の最新版は 1.1.1 だ。
これを使えば、自動的に TLS 1.3 に対応し、使用できる場合は使用される。
その際の設定などは、この記事の設定のままでいいはずだ。
（まだ試していない。）
さて、今まで http だった当サイトも、https に対応した。
SSL の対応状況を調べてくれる、Qualys SSL LABS でチェックしながら対応を進めた。
このページ、最高評価は A+ だ。
そして、このページで A+ を取るための方法、と書かれたページはたくさんある。
でも、それらのページを参考にしても A+ は取れない。
SSL に進展があったり脆弱性が見つかったりすると、チェック内容は変更されるためだ。
まぁ、A+ を取ることが正義ではないので、A- くらいとれていれば十分じゃないかな、と思う。
でも、例えば「設定が間違えていてアクセスできないブラウザがある」とかだと残念だ。
チェックはしておいた方がいいだろう。
そして、設定の中で一番重要になるのが、ssl_ciphers の設定だ。
これは OpenSSL に指示する、使っても良い暗号化形式のリストだ。
クライアントは、このリストの先頭から順に、自分が使える暗号形式を探す。見つけられればその形式でアクセスを行う。
どの暗号形式を許可するか？
これによって、安全性も大きく左右されるし、設定を間違えるとアクセスできないブラウザも出てくる。
目安としては、先に書いた SSL LABS のチェックを作っている人たちが、チェック項目の意味を解説しているページがある。
このページは、暗号に脆弱性が見つかる、などの状況変化により書き換えられる。
なので、以下の内容は記事執筆時点 (2016.10.22) のものだとお断りしておくのだけど、このようなことが書いてある。
・公開暗号鍵を 2048bit にすること
・SSL v2 / v3 には脆弱性があるから使わないこと。
・TLS v1.0 はあまり使用すべきではないが、まだ必要。
・TLS v1.1 と v1.2 は問題ないが、できることなら v1.2 を使うこと。
他にもいろいろあるのだけど、ssl_ciphers の設定に関係するのは以下のようなものだ。
・匿名 ADH は使用しない。
・NULL 暗号は使用しない。
・56bit 以下の弱い共有暗号鍵を使用しない。
・RC4 は安全ではない。
・3DES は遅く、弱い。
・出発点としては RSA および ECDSA を使うようにするとよい。
さて、具体的に ssl_ciphers をどのように設定すべきだろう。
そもそも、ssl_ciphers は「どうやれば」設定できるのだろう？
構築時に OpenSSL のソースを組み込んだことを思い出そう。
ssl_ciphers は、OpenSSL が解釈できる文字列で指示を与える。
指示にあるように「RSA および ECDSA を使う」のであれば
RSA ECDSA
と併記すれば良い。
試しに、openssl コマンドで、この指定を試してみよう。
openssl ciphers -v 'RSA ECDSA'
と併記すると、これらに関係する暗号の一覧が示される。
中には RC4 という文字列を含む暗号名も見られる。
これは「安全ではない」と示されているので、除外したい。
この場合は
RSA ECDSA !RC4
のように指定する。! は「除外する」という指定だ。
56bit 以下の弱い共有暗号鍵を使用しない、という指示もある。
実は、これは HIGH という表記で「128bit 以上」だけを選び出せる。
HIGH
この指定を行えば、RC4 は最初から除外されている。
実際には、ここを出発点とするといいだろう。
HIGH の一覧を出してみると、暗号名の後ろに Au=None と書かれているものがある。
「匿名のADHを使用しない」と指示にあるが、Au=None というのが「匿名」を意味している。
Au は Authorize 、認証の意味で、これが None 、つまり「認証しない」という、匿名を意味している。
これは、Au が NULL である、という表現をする。指示の際は aNULL 。
先ほどの指示からこれを除外しよう。
HIGH !aNULL
これだけで、とりあえず目的は達成できる。
他の設定も適切なら、A+ 評価を得られる。
でも、評価ページの詳細を見ると、いくつかのクライアントでアクセスができないことがわかる。
解消できるものならば、解消したほうがいいだろう。
まずは、次の2つだ。
Chrome 49 / XP SP3
Firefox 47 / Win7
どちらも同じエラーを出して、接続できていない。
SSL で使う暗号には、暗号利用モードと呼ばれる概念がある。
古い https 通信では CBC と呼ばれるモードを使う。
この方法は、直前の暗号文を鍵の一つとして使う。つまり、先頭から順番にしか暗号化できない。
でも、http2 では、１つのコネクションで複数のデータリクエストを並列に受付られる。
ということは、並列に暗号化を行う必要がある。CBC ではない方法を使わないといけない。
しかし、https では、クライアントが使用できる形式のうち、サーバーから渡されたリストの先頭に近いものを優先して使う決まりになっている。
サーバーが、クライアントが使える暗号形式の中で、CBC のものを先に渡してしまったために、それを利用しようとして http2 での通信ができなくなった、というのがアクセスできなかった理由だ。
評価サイトで、クライアント名の部分のリンクを辿ると、そのクライアントの詳細な性能が出てくる。
使用できる暗号化の形式もわかる。
とりあえず、上記二つのクライアントでは CBC 以外として AESGCM の形式を理解できる。
そこで、これらを優先して渡すことにする。
AESGCM HIGH !aNULL
これでいい。
いや、まだだ。
IE 8 / XP がアクセスできていない。
えー、もう XP はサポート範囲外だし、IE 8 なんて誰も使ってないからいいでしょ。…とも思う。
まぁ、無視してもいいと思うのだけど、乗り掛かった舟だから対応してみよう。
こちらも、使用できる暗号形式を見る。
うわ…さすがに古いので、セキュリティ的に問題がある暗号形式ばかりだ。
実用上、使えるものが 3DES しかない。
3DES は「遅く、弱い」とされているのだけど、脆弱性があるわけではないので、対応してみよう。
間違えて他のクライアントが使うと困るので、リストの最後に追加する。
AESGCM HIGH !aNULL 3DES
これでもまだ、対応できていないクライアントが２つある。
IE 6 / XP
Java 6u45
この2つへの対応を行うと、セキュリティ上問題が生じてしまうので、残念ながら切り捨てよう。
IE 6 / XP は、SSL には対応しているが、上位規格である TLS には対応していない。
SSL には脆弱性が見つかっているため、使用してはならない。
Java 6u45 は、公開暗号鍵として 1024bit までしか受け付けない。
1024bit では強度に問題があるため、2048bit を設定することが推奨されている。
とりあえず、話としてはこれで終わりなのだけど、この設定をしても妥当ではない場合もあり得るので説明しておこう。
OpenSSL は、バージョンによって、もしくはコンパイル時のオプションによって、使用できる暗号が異なる。
ここに書いた内容は、冒頭で書いたように 1.0.2j を前提としている。
SSL LABS で、各ブラウザが利用できると表示される暗号名は、OpenSSL のものとは違う。
でも、最後に16進で暗号を示す番号が書かれている。
OpenSSL でも、-v ではなく、-V （大文字）オプションを使うとこの番号を表示できる。
番号を頼りに、適切な暗号形式を探すといいだろう。
そしてこれが一番大切なことだけど、最初に書いた通り、時代と共に適切な暗号は変化する。
もしここに書いてある内容で十分でなかったら、その時点での推奨される方法を SSL LAB のブログで調べるといいだろう。
そして、除外すべきものを除外する。HIGH の指定を使っているので、おそらく「追加すべき」はあまりないと思うが、必要なら追加する。
SSL LAB のページは、一度評価を行うと、しばらくはその結果をキャッシュしている。
そのため、こちらが設定を変化させて、確認しようとリロードしても、評価を行ってくれない。
これは、ページ左上にある「Clear cache」のリンクに飛べば、再評価してもらえる。
最後に、もう一度まとめておこう。
2016.10.22 時点での最良の ssl_ciphers 指定は
ssl_ciphers 'AESGCM HIGH !aNULL 3DES';となる。
2016.10.25追記
SSL/TLS で使われる暗号について、わかりやすい説明をしているページを見つけた。
いろんなページを読んで理解して説明を試みたのだけど、長くなってしまうので書くのを辞めた部分。
専門的でわかりにくいかもしれないけど、なんとなく頭に入れてから設定を行うと、いろいろとわかってくると思う。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨日から、サイトデザインを変更している。
大体完了かな…と思っているけど、まだ多少手を加えたいところもある。
もし変更中に見に来た人がいて、崩れていて見られなかったら申し訳ない。
サイトのデザインは時々変えているのだけど、前回変えたのは、今調べてみると2013年5月だったようだ。
その時の日記に書いてあるけど、それ以前は、いわゆる3ペインデザインだった。
左と右に「さして重要ではない」情報が書かれていて、中央に本文があるの。
3年前にデザイン変更して、左側のペインを無くした。
無くした情報の一部は右側に吸収されたし、「画面上のヘッダ部分」にも表示した。
これは、そのころの流行のデザインを踏襲した…つもりだった。
でも、そのころから急にスマホ対応が進み始めたのね。
いわゆる、レスポンシブデザインが時代の潮流になった。
自分でもなんとかしたいなぁ、と思いつつ、忙しさと面倒くささでそのままになっていた。
今回、https/http2化を行ったので、「ついでに」デザインの改修にも乗り出した。
で、結局元の3ペインに戻った。
戻ったのだけど、いわゆるレスポンシブデザイン。
画面幅によって適当に見た目を変化させるようになっている。
まず、以前の3ペインは、本当に画面を…HTML 上の位置を、３つの領域に分けてあるだけだった。
今回は、左と右はスクロールしても画面内にとどまり続ける。
これはレスポンシブとは関係ないけど、最近よく見るデザインだね。
画面が狭くなると、右のペインが消滅し、本文下に異動する。
なぜなら、右のペインの情報の多くは、このサイト内の関連ページの紹介だから。
ずっと見えていて興味を持ってもらえればうれしいのだけど、画面が狭くなったら「読み終わった後に次記事の紹介」でいい。
ちなみに、今までも右のペインはあったのだけど、これは「画面が狭くなったら、余分な情報だから外に追い出されてもいい」というつもりだった。
WEB ブラウザは、ブラウザのウィンドウよりも HTML/CSS の指定のほうが大きい場合、左上から表示して、右側を画面外に追い出すから。
これが、明示的に「下に」追い出されるようになったわけだ。
スマホの場合、フリックで操作すると上下だけでなく、左右に動きやすいため、追い出しを明示して WEB の横幅を画面幅と一致させることには意味がある。
さらに画面が縮むと、左のペインがさらに左に…画面外に逃げる。
と同時に、左下に ⇔ というボタンが常駐するようになる。
ご察しの通り、ここをタップすれば、左からペインがひょっこり顔を出す。
左ペインは、サイト内での現在記事の位置を示す役割と同時に、周辺記事への案内を行っている。
読み進むうえでは一応重要情報なので、いつでも呼び出せるようにしてあるわけだ。
いちおう、Windows 上の Chrome / FireFox / Opera / IE11 / Edge / Safari と、MacOS X 上の Safari で画面が崩れないことを確認している。
IE 以外のブラウザは、自動アップデートの仕組みを持っているので最新版…せいぜい、ここ1年くらいのバージョンしか使われないだろう。
Win の Safari は、とっくにサポートが切れていて、最新版が 2012 年のものだ。
それでも動作しているのだから、まぁ古いバージョンでも大丈夫だと思う。
問題は IE 系列。特に IE 8。
ちなみに、IE 7 以前は SSL 対応に問題があるため、すでに当サイトにアクセスできなくなっている。
そして、サーバーログを見る限り、わずかとはいえまだ IE 8 は使われている。
先にレスポンシブデザインの仕組みを書いたのだけど、実は右ペインが下に落ちた「２ペイン」の状態を基本に作ってある。
IE 8 では、メディアクエリを理解できないので、画面幅を変えても画面構造は変わらない。
…実環境では確認していないので、もし動かなかったら申し訳ない。
その時は諦めて、IE8 でアクセスしている人は、そろそろ新しいマシンの購入を検討してほしい。
＃IE8 も、WinXP もすでにサポート期限を過ぎています。
古いけど使える、ではなく、いつ爆発するかわからない爆弾を抱えている状態です。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【chrome】 きれいに見れるようになってます。対応ありがとうございます。 (2016-11-10 09:22:17)【あきよし】 報告ありがとうございます。windows chrome では動作確認しているのですが、違う環境かな…できるだけ多くの環境で見られるように整備したいので、確認して修正したいとおもいます。 (2016-11-09 10:12:10) 【chrome】 chromeで見ると左のペインが中央の本文とかぶってしまい、とても見づらい状態です。 (2016-11-08 10:57:50) |
十数年ぶりにセガサターンに通電した。
１年前に「遊びたいな」と思って探したら、本体は出てきたのだ。
でも、電源ケーブルとAVケーブルがなかった。
どうやら、11年前の引っ越しの際にケーブル類を別の場所に入れてしまったようだが、どこにあるのか全く分からない。
…で、2週間くらい前に、ネットでAVケーブルを買った。今更サターンのケーブルなんて激安だと知ったから。
電源ケーブルは、いわゆる「メガネケーブル」で、プレステとも共有できる。
そもそも１年前に「遊びたい」と思ったのは、コラムス 97 だったのだ。
本体が動かないから仕方なく、Win 上のエミュで動かしていた。
エミュでもそれなりに動いたのだけど、やっぱり実機は綺麗だと再確認。
コラムス97 は変な画面モードを使っているので、エミュだと見た目が汚くなってしまう。
＃インターレースモードを使っているのだが、エミュではインターレースがうまく表現できず、シマシマの表示になってしまう。
今更だけど、２Ｄゲームでの表現力の高さはやっぱりすごい。
当時は NTSC の家庭用テレビで見ていたわけだけど、ハイビジョンテレビにつなぐと綺麗さが際立つ。
もちろんハイビジョンのグラフィックとは違うわけだけど、当時のゲームに多く見られた解像度は 320x240 。
でも、コラムス 97 やエジホンは 704x448 で作られている。
当時のテレビではこんな高解像度は表現できなかったのに、その画面モードを使うなんて馬鹿じゃないのか。
＃当時でも、高解像度モードではやっぱり綺麗には見えたのだけど。
我が家の子供にはコラムス97は難しすぎてウケが悪かったのだけど、エジホンは大ウケ。
ゲームが「怖い」ので遊べない、小１の次女でも、間違い探しは横から参加できる。
ついには次女もコントローラーを手に取り、長女（小３）と一緒に仲良く遊んでおります。
＃ちなみに、長女は四葉探しが得意。同じようなものの中から、わずかな違いを見つけ出す能力がある。
本気を出すと喧嘩になるので、見つけると次女に「答える権利」を譲ったりしながら遊んでいる。
点数にはこだわっていない。だって、エジホンの勝敗は最後の「賞金の奪い合い」で決まるのだから。
（最期の一発勝負は両者本気で、どっちが勝っても…モショ郎に持って行かれても…ゲラゲラ笑ってる）
ところで、唐突に我が家の子供の「ゲーム履歴」。
うちのゲーム機は、Wii / Playstation 3 の時代で止まっている。
なので、最初に遊んだゲーム機は Wii 。続いて、NintendoDS 。PSP も遊んだな。
ここらへんでゲームに興味を持ち、棚に置いてあったゲームソフトなどを見始める。
あまり興味を持つものは遊ばせる。GameCube のソフトなどは、Wii でも遊べるので比較的早くから遊んでいた。
そして、わざわざ古い機械を引っ張り出して、PS2 / PS1 のゲームも遊んだ。
最近になって、GameBoy Advance にも手を出している。
で、今回はセガサターン。
見事に、ゲームの歴史を遡って行っている。
メガドライブは持っているけど、ソフトがぷよぷよとバーチャレーシングしかない。
というのも、本体はサターン時代になってからの貰い物で、あまり遊んでないんだよね。
ファミコンは、本体だけ残っていてソフトがない。
先日結婚した甥っ子が小学生の時に、全部あげちゃったから。
（貸しただけだったような気がするのだけど、今更どうでもいいや）
今は品薄だけど、ファミコンクラシックミニが売っていたら買おうと思っている。
それで子供にも遊ばさせてやろう。
ちなみに、「それ以前」については、PS2 用のタイトーメモリーズとか、ナムコアーケードHITS! とかで遊んではいる。
PONG は遊んでいないけど、長男は SPACE WAR! はちょっとだけ遊んでいるし、迷路のネズミも動作を見てはいる。
なので、ファミコン～メガドライブ当たりのゲームを見れば、大体の歴史の流れは理解できるようになると思う。
＃だからどうした、というわけではないのだけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
仕事で VPN が必要になった。
VPN 、Virtual Private Network 、の略だ。
今まで使う必要はなかったのだけど、インターネットではよく使われる技術で、Windows8 以降では、システムに標準で組み込まれている。
インターネットというのは、そもそも「ネットワーク」を相互 (inter-) 接続したものだ。
それぞれのネットワークは独立していて、状況によっては、接続しているにもかかわらず閉じている。
会社なんかで「社内ネットワーク」という言葉を聞いたことがある人も多いだろう。
社内のネットワークは、社内からはアクセスできるけど、外部からは守られている。
そうしないと、社外秘の情報とかが外部にダダ漏れになるかもしれないからね。
会社の社内ネットワークにありながら、外部に開かれている「WEB サーバー」などもある。
こうしたサーバーは、「社内」を囲む壁にまたがるように設置されている。だから、どちらからも見ることができる。
ただまたがっているだけじゃない。
サーバーは社内と社外を区別する。社内からはページの書き換えもできるけど、社外からは見るだけで、それ以外の動作は一切できない、というような設定が行われている。
つまり、ある場所に作られた「ネットワーク」は、基本的に閉じた系を作っている。
閉じた壁の上に置かれたサーバーは、外部からも見えるのだけど、内部と外部を見分ける能力がある。
本当は細かな技術とかいろいろあるのだけど、ざっくりいえばこんな感じ。
じゃぁ、WEB サーバーのページを更新しようと思ったら、必ず会社内まで物理的に移動しないといけないのか。
いや、そんなことはない。ここで VPN が登場する。
社内…つまり Private な Network を、仮想的 Virtual に実現するのだ。
WEB サーバーのように「壁」にまたがる形で、VPN サーバーを作っておく。
VPN クライアントが VPN サーバーに接続すると、VPN サーバーはクライアントを代理し、「社内ネットワークに新たなマシンが接続された」ように振る舞う。
たぶん、社内には DHCP サーバーがあり、新しいマシンが接続されると社内用の IP アドレスを払い出す。
クライアントは、もともとの IP アドレスに加え、新たな IP アドレスも得る。
これでクライアントは、社内 LAN に接続した状態になった。
…のか？
一応、VPN の設定としては上の通りで正しい。
お使いのマシンには二つの IP アドレスが割り振られ、社内 LAN に接続されたマシンとしての IP アドレスも使える状態になっている。
でも、優先されるのはもともと持っていた IP アドレスだ。
今まで通り社外のマシンとしてインターネットに接続し、会社のサーバーにアクセスしようとしても、できない。
元々の IP アドレスよりも VPN の IP アドレスを優先させる、という設定は可能だ。
でも、これをやった場合は、今度は完全に社内 LAN に組み込まれた状態になり、通常使用していた IP アドレスを使わなくなる。
今回の場合がそうだったのだけど、家庭内 LAN に組み込まれたマシンで VPN に接続すると、家庭内のサーバーが見えなくなる。
これは不便だ。
Windows に限らず、ネットワークには「ルーティング」という概念がある。
通信時に使う経路… route を決める作業だから、routing だ。
VPN を使うことで、マシンには二つの「道」がつながっている。先に書いた通り、VPN の経路が優先されてしまうが、そうならないようにルーティング規則を書いてやればよい。
この規則は、VPN に接続を行ったときと、切断した時に書き換えられる必要がある。
すでにそのためのスクリプトが作られていて、参考にさせてもらった。
リンク先を見てもらえばわかるが、スクリプトは自分の接続する VPN 環境に応じて、少し書き換える必要がある。
ここで重要なのは、ルーティングの際には「接続先 IP アドレス」を参考にして、マシンが持っている2つの IP アドレスのどちらを使うか決定する、という点だ。
先のスクリプトに登録した IP アドレス（上位3バイトによる範囲指定）は、VPN 経由となる。
それ以外のすべては、家庭内 LAN を使う。
さぁ、これで正しい設定か？
いや、実はまだ正しい設定にはなっていない。
マシンに設定された DNS サーバーアドレスは、今までのままなのだ。
社内サービスのサーバーにも、おそらく名前がついているだろう。
そのサーバー名に応えてくれるのは、おそらくは社内 LAN に置かれた DNS サーバーだけだ。
だから、DNS サーバー名を書き換えなくてはならない。
先のスクリプトを改造しよう。
たとえば、社内 LAN の DNS サーバーが 172.16.0.1 と 172.16.0.2 に置かれていたとしよう。
WindowsPowerShell では、DNS サーバーの設定は Set-DnsClientServerAddress で行う。
マシンは複数のネットワークに接続した状態になっているけど、これらのネットワークには名前がついている。
おそらく、Windows 10 の日本語版なら「イーサネット」が標準ネットワークだ。この DNS を書き換える。
Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ServerAddresses "172.16.0.1","172.16.0.2"
スクリプトでは、VPN 接続に成功すると、プログラムが最後まで走りきる。
だから、この1行を一番最後に追加しよう。
もう一つ、VPN 切断時に、家庭内 LAN の DNS に戻す必要があるだろう。
こちらは、プログラム中ほどの if 文…if ブロック内に exit; が入っている上に入れる。
VPN 接続がなかった場合は、この if 文によって終了しているためだ。
これで、VPN 接続すると、VPN 接続先の IP アドレスだけは VPN に流すようにルーティング設定し、VPN 接続先の DNS を使用する状態になる。
切断すれば元に戻る。
…そう、気づいた人も多いだろうけど、VPN 接続中は家庭内 LAN の DNS が使えない。
DNS は解決できない時のための「代替サーバー」を置くことができる。
これを使えば解決できそうだけど、実はうまくいかない。
理由は、WEB サーバーなどには社内アクセス用と公開用で、違うアドレスがついているのが普通だからだ。
家庭内 LAN の DNS が社内 WEB サーバーの名前解決をしてしまうと、その時点で社外からのアクセスとなってしまい、VPN 経由のアクセスとならない。
＃実際には、Windows は名前解決手段として、ありとあらゆる手法を駆使することも問題ともなる。
名前解決手段が多数あるのは便利なのだけど、混乱も引き起こす。そこに違う内容の DNS サーバーを「代替」として混ぜると、破綻を招く結果となる。
たとえ上のような「2つのアドレス」の問題がない場合でも、やってはならない設定だ。
仕方がないので、VPN 接続中に困らないように、最低限の家庭内 LAN のホスト名を hosts ファイルに書くことになる。
原始的な方法だけど、原始的だから信頼ができ、応用が利くのだ。
windows の hosts ファイルは C:/Windows/System32/drivers/etc/hosts にある。
家庭内 LAN 全体を VPN 接続してしまえば、上手く解決できるかもしれない。
DNS サーバーは、問い合わせられたドメイン名ごとに、問い合わせ先 DNS を振り分け（フォワード）する仕組みを持つ。
だから、社内 LAN で使いたい名前だけ、社内 LAN DNS に問い合わせるよう設定すればいい。
でもそれは、家庭内 LAN 全体を、ここに書いたような不安定さを含む問題のある VPN に巻き込むことになる。
それは嫌なので、今回はそこまで踏み込まず、Windows 1台だけを VPN 接続することにした。
Windows 自体に、ドメイン名ごとに DNS サーバーを切り替える機能があればいいのだけど、調べてもそのような機能は無いように思う。
最後に、ネットワークが正しく設定できか、確認方法を書いておこう。
コマンドプロンプトを使う。
（先ほどのスクリプトは PowerShell 用だったが、以下のコマンドはコマンドプロンプト用なので注意）
マシンにつけられた IP アドレスは、以下のコマンドで見ることができる。
（途中で書いたが、普段使う IP アドレスが「イーサネット」と名付けられていることも、ここで確認できる）
netsh interface ip show address
現在の DNS サーバーは、以下のコマンドで調べることができる。
netsh interface ip show dnsservers
ルーティング設定は以下のコマンドで見ることができる。
route print
DNS サーバーに接続し、問い合わせを行った結果を表示するには、以下のコマンドを使う。
（途中で書いたが、Windows は複数の問い合わせ方法を持つ。
このコマンドは DNS のみを扱うので、実際の処理と異なる場合がある）
nslookup host.domain
実際にパケットが通過する経路を調べるには、以下のコマンドを使う。
tracert host.domain
コマンド名は示したので、使い方の詳細などは検索すれば簡単に見つかるだろう。
これで、VPN 側でアクセスしたいサーバーへの通信が正しく VPN に流れ、それ以外の通信は VPN に流れないことを確認できれば、ネットワーク設定は完了だ。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
仕事でハマった事例があって、同じことで悩んでいる人がいそうだと感じたので書き記しておこうと思う。
最初に、事象を説明しておこう。ここで意味が分からない人は、この記事を読んでも意味が無いと思う。
・Cordova / Phonegap でスマホ用のコンテンツを作っている。
・<input type="file"> を使ってスマホ内のファイルを選択し、Javascript でその内容を得る。
・iOS とブラウザでは動くのだけど、Android では環境により、ファイル選択できたり、できなかったりする。
まずは、上にある事象を「乗り越えた」。
上の事象で困っている人もいるかもしれないから後で解説するけど、乗り越えたうえでさらに問題がある。
・ファイル選択は出来たが、得られるものが違う。
iOS と同じ動作にさせるのに、どうしたらいいのかわからない。
原因は、Android ではセキュリティの問題で WebView からローカルファイルが扱えないこと。
ただし、これは途中のバージョンからの仕様なので、「過去との互換性」を気にして、扱えるようにしてある端末もある。
だから、端末によっては動くのに、別の端末では動かないことがある。
原因が特定しづらい、最初のハマりポイントだ。
この問題を「乗り越える」には、Android では file chooser の plugin を使う。
プラグイン自体は多くの人が作っていて、ほぼ同じ動作なので好きなものを使えばよい。
僕はdon / cordova-filechooserを使った。
他のものに比べ、制御用のオプション指定が無い。制御が不要であれば軽量で使いやすい。
HTML の Content-Security-Policy に file: blob: cdvfile: を追加すること。
そうしないと、Javascript からローカルファイルを扱えない。
file: はローカルファイルを意味する。blob: はローカルファイルの中身をデータとして扱う指定だ。
cdvfile: は、Cordova 独自の file 拡張機能を扱うことを意味する。
さて、これでファイル選択ができるようになっても、得られるものが HTML5 で得られるものと違う。
この違いを乗り越えるのが結構ややこしいことになる。
HTML5 の input file で得られるのは、Javascript の「file object」だ。
ファイル名やサイズ、更新日などと共に、ファイルの中身を読み取れるようになっている。
android の fileChooser で得られるのは、ファイルの「コルドバ拡張の」パスだ。
これは cdvfile: スキームで表現される。
特殊なスキームだけど、気にすることはない。
例えば、img タグにこのスキームを渡せば、そのまま画像ファイルを表示できる。
まぁ、ファイルを選択するという目的にはかなっているのだけど、得られるものが違う。
HTML5 / iOS で動くプログラムでは、file object を得られているのに、cordova では file path しか得られないのだ。
僕の場合、file object をそのまま受け渡すライブラリを使っていたので、できれば file object が欲しかった。
window.resolveLocalFileSystemURL を使うと、ファイルのパス名を fileEntry オブジェクトに変換できる。
fileEntry には file メソッドがあり、file object を取り出せる。
これで目的の file object を得ることができた。
// iOS / HTML5 の file タグ
$("input:[type=file]").on("change",function(e){
getFile(e.target.files[0]);
});
// 上と等価な Android の fileChooser
function fail(){alert("error");};
fileChooser.open(function(path){
window.resolveLocalFileSystemURL(path,function(fileEntry){
fileEntry.file(function(file){
getFile(file);
})
},fail);
},fail);
getFile に file object が渡されればよい、というプログラムであれば、こんな感じかな。
ただし、まだ問題がある。
cordova の File API 関連は拡張されている。
というのも、アプリを作成するのであれば、自由なファイルアクセスや、ファイル書き込みも欲しいから。
Javascript では、セキュリティのためにファイルアクセスは基本的に禁じられているし、書き込みもできない。
これらを実現するために、cordova では File API 関数群は全部互換品に置き換えられている。
しかし、ここで問題が生じる。
Android で得られる file object は、cordova による「互換品」であり、HTML 5 の file object とは違うものだ。
HTML5 には、Blob がある。
Blob っていうのは捉えどころのない塊の意味合いがあるのだけど、プログラムの用語としては binary の塊のことだ。
旧来の Javascript では、バイナリは「文字列」として扱ったのだけど、HTML5 ではより効率よく扱える Blob という概念ができた。
file object は blob object から派生したものになっていて、バイナリの塊と共に、ファイル名やサイズ、更新日付などを持っている。
そして、blob も file も、「とらえどころのない塊」なので、そのままではデータとして扱えない。
必ず、データを取り出したり変換したりするメソッドや関数を使用して扱う。
さて、cordova では、こうした「関数」レベルで互換性を保っている。
ところが、僕が使っていたライブラリでは、blob を渡されたかどうかを、データの型を確認して確かめていた。
file は blob から派生したものだから、blob として認識される。でも、それ以外のものを渡されると、エラー終了する。
まぁ、当然の処理なのだけど、cordova の file object は、HTML の blob の派生ではなく、独自の構造体に過ぎなかった。
だから、cordova の file object が得られたからと言って、iOS の file object と同じように処理を行っても、動かない。
ここは非常に厄介なハマりポイントだった。
結局のところ、Android では「そのライブラリを使わない」という決断をせざるを得なかった。
ライブラリを改造しても良かったのだけど、ある程度の規模のものを改造するのであれば、改めて「動作検証」をしないといけないし、今後ライブラリがバージョンアップされるたびにそれを繰り返す必要がある。
そうした手間はかけたくなかったんだ。
幸い、そのライブラリは「各実行環境での差異」を吸収するためのものだったので、Android だけなら独自に書いてもそれほど難しくはなかった。
別の手段として、自前で blob を用意してライブラリに渡す、という方法も考えた。
file object は当然データを得られる。これは cordova でも一緒だし、そうでないと意味がない。
そして、データがあれば blob を生成できる。
ところが、調べてみるとこちらにも問題があった。
blob は元々「ファイルや、ネットから得たデータなどを上手に扱う」ためのもので、入力を前提としていた。
生成する方法も後から策定されたのだけど、ドラフト時点と正式決定時点で方法が違っている。
このため、Android のバージョンにより、blob を生成する方法に差異がある。
Android 4 までと、5以降で実装されている方法も違う…「らしい」。
らしいというのは、僕自身が実機確認できていないから。
確認できない不安があるのであれば、比較的古くて安定動作が望める仕様を使ってプログラムを作るしかない。
最終結論としては、Android の file 周りは、iOS / HTML5 と「共通化しづらい」ことになる。
iOS や HTML 5 では、ファイルを選択した結果 file object が得られる。
しかし Android では file path しか得られず、fileEntry に変換したうえで file object を得ないといけない。
そうやって得た object は、できるだけ互換を保つ努力はされているが、完全互換ではない。
file を受け取るライブラリ等を使用している場合、そのライブラリは動かないかもしれない。
Android で blob を作り出せれば問題は解決しそうなのだが、Android のバージョン間で blob の生成方法には違いがある。
そのため、この方法を使うのは注意が必要だ。
しかし、問題は所在が分かれば解決できる。
解決方法は、そのプログラムごとに違うだろうが、ここに書いたことがヒントになれば幸いだと思う。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ふと気づくと、このサイト「魔法使いの森」も、いつの間にか20年を超えていた。
最初に書いた記事はファミリーBASICで、1996年の10月1日に公開していたようだ。
僕がこのサイトを作り始めたきっかけは、セガ社内での「流行」があったからだった。
なので、個人的なことなのだけど、業界記タグで書いてみよう。
以前に書いたことがあるのだけど、パソコン通信は、1991年に始めたと思う。
電話事業の民営化でパソコン通信が可能となったのが 1985年。
高校の頃読んでいた MSX マガジンでも、パソコン通信の記事とかがずいぶん出ていた。
1991年だとすでにブームもひと段落して、機材が手ごろに購入できるようになってきた。
そこで、「すっかり出遅れた」と思いながら始めたのだった。
1994年には WWW が普及し始め、「ホームページ」が続々作られ始める。
それまでは、インターネットに接続しようと思うと、大学などの研究機関同士のネットワークに参加するしかなかった。
同じ 1994 年には IIJ が接続サービスを開始。
でも、まだ非常に高くて、個人が使うようなものではなかった。
1996年頃になると、個人でも使える接続サービスが増えて、競争で値段が下がってくる。
でも、やっぱり僕はパソコン通信で十分で、インターネットには接続していなかった。
大学の卒業研究が「ハイパーテキストによる執筆環境」だったので、 WWW に興味はあった。
セガの社内は、当時まだ 10Mbps だったのだけど、Ethernet で接続されていた。
社外にも接続されていたのだけど、使用するには許可が必要だった。
でもある日、当時セガが作成していた「ホームページ」（当時は WEB サイトのことをそう呼んでいた）が、社内から見られるようになっているのを知った。
セガ公式とはいえ、情報はわずかで、ほとんどがファン同士の交流掲示板だった。
そして、社内で見られるのは深夜 0 時時点のスナップショット。
掲示板の話題は最新ではないし、こちらからは発信できない。
でも、WWW を体験してみるには十分だった。
ホームページは社内の情報部署が作っていたようなのだけど、その部署の人が「個人ホームページ」もサーバーに置いているのを知った。
こちらは非常に個人的なことしか書いてなかったし、当時の個人ホームページらしい、自分の趣味の紹介を書いてあるだけ。
ほとんど更新されなかったけど、時々見に行っていた。
そして、さらに全く違う部署の人も、「個人ホームページ」を公開していることがあると知った。
その人のマシンの IP アドレス直打ちで接続しないといけないし、案内はどこにもない。
でも、出来の良いページを作っている人の IP アドレスは口コミで広まっていた。
そんな社内で人気の WEB ページの一つが、どこかの部署のデザイナーさんが作っていたページだった。
当時の Mac … OS 8 には OS 標準で httpd 機能があって、ページを公開できたのを利用して作られていた。
個人のマシンで直接公開しているので、その人が勤務中しか見られない。
週一回更新されていて、デザイナーさんらしく「扉絵」を 3D CG で描いていた。
毎回ゲームをテーマにしたイラストで、主人公キャラが必ずミッフィーちゃんになっている。
まず、この CG の出来が良かった。
簡単なつくりだけど、ちゃんとそのゲーム「らしさ」を出していたし、主人公をミッフィーちゃんにしてもちゃんと成立するような図柄にデフォルメしてある。
それを、毎週描いているというクオリティの高さ。
もっとも、ページ内は、非常に短い４コーナーだけ。
写真主体で、ちょっと文章がついていただけじゃなかったかな。
先に書いたけど、この頃のホームページって、自分の趣味を紹介したりするのが普通。
その紹介も「プログラムと料理が趣味です」とか書いてある程度で、詳細に踏み込まない人が多かった。
それを、毎週短い記事とはいえ、趣味丸出しで情報を発信している。
これが、会ったこともない人なのに性格がわかって面白い。
僕もこういうページを作ってみたい、と思い始めた。
幸い、パソコン通信環境はある。あとはプロバイダに申し込めばインターネット接続できる。
プロバイダへの申し込みを進めると同時に、どんなページを作ろうか考え、記事を書き始めた。
やっぱりページは４コーナーで構成して、自分が趣味丸出しにできるものにしよう。
作成期間は、確か 2週間くらい。
「Old Good Computer」「社会の歯車」「男の料理（現在「簡単料理の作り方」に改題）」「森の生活」の４コーナーで構成される「魔法使いの森」はこうして公開された。
当初は真似をして毎週更新していたのだけど、だんだん記事が長くなり、書くのが辛くなって毎週更新はやめた。
（今はほぼほったらかしで、申し訳ないと思っている）
先に書いた、デザイナーさんが作っていたページに、告知が出た。
せっかく作っているのだから、インターネットで公開します。URL が添えられていた。
そして、しばらく後には、社内ページは閉鎖されて、インターネット公開のみとなった。
それまでは作者さんに連絡する手段がなかったのだけど、ネット公開になって連絡できるようになり、しばらく仲良くしていただいた。
その後、ベンチャービジネスに参加するためセガを辞める、と聞いた。
そしてさらに後、作成していたソフトが完成したと、ご自身のページで公表していたと思う。
ピンク色のクマのぬいぐるみがメールを運ぶ、不思議なメーラーソフトだった。
ポストペットの公開は1997年 1月だったそうで、20周年のお祝い記事を読んで、上記のことを思い出した。
当サイトが参考にしたページは「ナミ通」。
ポストペットのキャラクターデザイナーである、真鍋奈見江さんが作成していた。
WEB ページ作成時も参考にさせてもらったし、ポストペットの成功は「うまくやったなぁ」と、正直羨ましかった。
僕も何か自分の力でやってみたかったけど、そのために会社を辞めて独立するというのは、なかなかできるものではない。
僕も後でセガを辞めて独立したのだけど、こうした成功者に触れていたことは後押しになったように思う。
＃直接的にはやはり同じ部署で独立した、同期の女性デザイナーの成功のほうが大きかったと思うのだけど。
こちらの話はまたそのうち書きます。
まぁ、そんなわけでポストペット 20周年おめでとうございます。
今は交流はないのだけど、その当時仲良くしていただいた者として…そして、会社経営者として、20年会社を維持したことはすごいと思うのです。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
お仕事で、とあるWEBサイトの内容修正を手伝った。
スマホと PC で同じ html で動作して、それぞれの環境にあった見栄えになるように作られている。
いわゆるレスポンシブデザイン。
ところが、スマホで表示すると、本来画像が出るはずの部分で消えてしまうという。
僕への依頼は、このバグを解消することだった。
PC の Chrome には、開発者モードがあって、表示中の html などを調べたり書き換えたりできる。
また、この際スマホをエミュレートするモードがある。
スマホの時だけうまくいかない、というので PC 用のページとスマホ用ページを見比べる。
同じ html のはずなのに、読み込んでいる画像のファイル名が違う。
でも、「ファイル名が間違っていて読み込めない」とかではない。読み込みエラーは出ていない。
画像に対する style 指定で、width:0px が指定されていた。
なるほど、画像は表示されているけど、小さすぎて見えないのか。
いったいどこでそんなことをしているのか…
と、読み込んでいる複数の javascript プログラムを探してみると、見つけた。
スマホでは「物理ピクセル」と「論理ピクセル」が一致していない。
文字の大きさとして 12px と指定された文字は、24px で美しく描画される。
というのも、初期の iPhone などでは、12px は 12px だったのだ。
Retina ディスプレイが搭載され、解像度が2倍になった時に、過去との互換性のために「解像度は2倍だが文字の大きさは変わらない」仕組みがとられた。
そのため、12px は 24px で描画される。
横方向が 120px の画像があれば、240px に引き伸ばして描画されることになる。
解像度をあえて落とす表示だ。
問題となるプログラムでは、この問題を解消するために、画像サイズを半分にして表示しようとしていた。
そのために、画像サイズの半分のピクセル数で表示するように、style 指定を行う。
ここにバグがあり、必ず 0px になってしまうようだった。
まぁ、WEB プログラム経験がある人なら「画像のサイズを半分にして設定」でどんなミスをしたかわかるだろう。
問題のプログラムでは、jQuery を使い、$(document).ready イベントで画像の width を指定していた。思った通りだ。
WEB ページは、まず HTML が読み込まれる。
読み込まれた後でタグの内容などの「解釈」が行われ、img タグがあれば、その src を読み込む。
読み込み終われば、img 部分を読み込んだ画像サイズに整え、ページ全体を配置し、表示する。
もっと細かな話もあるが、これが大まかな流れだ。
そして、$(document).ready は、「HTML を読み込み終わり、まだ画像など関連ファイルは読み込み終わっていない」段階でプログラムを動かす。
関連ファイルの読み込みって遅いから、遅い作業を待たずに必要な処理を始めることで、全体の速度を上げるためのものだ。
もうわかると思うが、元のプログラムでは、「画像サイズを半分に設定」しようとする時点で、画像がまだ読み込まれていない。
画像サイズの半分を設定するが、そもそも画像がないので 0 になってしまう。
解決方法は簡単で、$(document).ready ではなく、$(window).load を使えばいい。
前者は、HTML を読み込み終わったら実行されるが、後者はページに関連するすべてのファイルを読み込み終わったら実行される。
プログラムでは、スマホか PC かを見分けて、違う画像を読み込ませる仕組みも用意されていた。
…と、説明しようと思っていい例がないか探したら、こちらのページで紹介されているプログラム、ほぼそのままだった。
HTML を読み込んだら、画像を読み込む前にファイル名を加工してしまう。
違う画像にしたい場合に与える class まで同じだ。
こちらはうまく動いている、と思ってたのだけど、検索してコピペしただけだったのか。
…あー、なんかわかった。わかっちゃった。
「画像サイズを半分にするプログラム」も、これと同じだと思って改造したんだな。
だから、$(document).ready をそのまま使っていて、$(window).load なんてそもそも知らなかったのか。
ところで、プログラムでは、半分サイズにしたい画像を指定できるようになっていた。
画像の class として、 harf という文字列を与えておけばよい。
…半分にするのだから half じゃないかと思うのだけど、プログラムは harf と指定していた。
そして、HTML 内にも当然のように harf という class が大量に…
もうね、この時点で「このプログラムは信用できない」と考えていいと思うよ。
この class 名は、「なんだっていい」ので、綴りをミスしたこととプログラムは関係ない。
でも、こんな単純な単語を綴りミスして、人様から見える HTML 内に大量に書き込んでいるという時点で、かなり注意力の低い人であることがわかる。
「些細なミス」だけど、バグというのはもともと些細なミスなのだ。
些細なミスを残す人のプログラムというのは、些細なバグもいっぱい残っているに違いない。
とりあえず、この仕事は「１時間程度で解決できないようなら保留で」と言われたくらい締め切りが短かったので、他の部分は見なかったけど。
（余計な仕事が増えそうなので見たくもない）
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はロバート・ウィリアム・バーマーの誕生日(1920)
愛称は「ボブ」。Robert は一般に Bob になります。
＃Rob なのだけど、R の音は発音しにくいので、変化させて B になる。
さて、ボブは ASCII の父として知られています。
以前、世界で最初に { } （弓括弧）を使えたマシンは何だろう、という疑問を調べたことがありあす。
今は、非常に多くのコンピューター言語が、{ } を使います。
これらの最初は BCPL という言語だ、ということになっています。
だけど、昔のマシンでは { } は使えませんでした。
BCPL は { } を使ったというけど、その時代のマシンでなぜ { } が使えたのか？ という謎を追ったのでした。
実は、この過程で昔のコンピューターで使える文字セットに興味を持ち、言語との関係や変遷をまとめたのだけど、まだ記事にしていません。
いつか記事にしたいのだけど、タイプライターと文字セットと言語と…と、密接な話題が入り組んで整理しにくいの。
それはさておき、昔のコンピューターにはタイプライターが接続されていました。
そして、タイプライターは活字を持たなくてはならない都合上、それほど多くの文字を扱えませんでした。
これらのタイプライターは「テレタイプ」と言って、操作を紙テープに残せました。
このため、「文字コード」も持っているのですが、各社でバラバラ…いや、場合によっては同じ会社でも互換性がありません。
そこで、統一コードが作られます。これが ASCII です。
当時のタイプライターの紙テープは、5～6bit 記録でした。
しかし ASCII は 7bit として制定され、今までよりも多くの文字を使えるようになったのです。
そして、ボブ・バーマーは ASCII の定義委員の一人でした。
彼は { } や ＼ （バックスラッシュ）、制御コードとしての「ESC」など、多数の文字を入れるよう提案を行っています。
これらの文字は、単に「入れたいから入れよう」というような話ではなく、よく考えて決められています。
当時は、ALGOL が「最良の言語」でした。そして、 ALGOL では、論理演算に ∧ ∨ という数学記号を使います。
だから「それらの文字を入れるべきだ」という意見も出ていました。
しかし、ボブは、すでに入っている / （スラッシュ）に ＼ を組み合わせれば、論理演算記号を表現できる、と提案したのです。
一部の言語しか使わない文字ではなく、より普遍的に使える文字を入れる。
長く使われる「標準セット」には大切な考え方でした。
そして、ESC は特に重要な提案でした。
ASCII では、「文字コード」を定めようとしていましたが、それは各社のタイプライターの差がなくなってしまうことでもありました。
タイプライターメーカーとしては、新機能を搭載しづらい…業界の進歩が止まってしまうことになります。
ASCII を決定したとしても、いつか新機能を搭載したがったメーカーが「新しい文字コード」を使い始めるかもしれません。
それでは標準コードの役に立たないのです。
ESC は、この問題を解決する素晴らしいアイディアでした。
ESC 文字コードが送られてくると、タイプライタは、ASCII 文字コードから「ESCAPE」…脱出できます。
ESC に続いて送られてきたデータを自由に解釈し、タイプライターメーカー独自の機能を追加できるのです。
ビデオ端末が登場すると、この機能により自由な位置に「カーソル」を動かしたり、文字に色を付けたりできるようになりました。
これによって、初期のテレビゲームや、ワープロなど…「グラフィカルな」ソフトウェアが作られ始めます。
もし ESC が無かったら、端末は文字しか出せないままで、コンピューターの利用用途はずっと限られていたでしょう。
このことから、ボブは「ASCII の父」と呼ばれるのです。
彼は 2004年に亡くなっていますが、彼の作っていた WEB ページはそのまま保持されています。
そのページから、写真を引用させてもらいます。
彼の乗っていた車のナンバーは「ASCII」でした。
＃2018.10.15 追記
さすがにページが消えたようです。
webarchive に、2018.5.11 時点のアーカイブが残っていましたので、リンク先を変えました。
ナンバープレートも同様です。
ボブは、IBM 、ハネウェル、UNIVAC など、コンピューター黎明期の大メーカーを転々としながら働いています。
ASCII コードの定義委員をやっていたのも、IBM の代表の一人として。
IBM が FORTRAN (1956) を発表した後、ボブは彼自身のプログラム言語を考案しています。
FORTRAN は科学者向けの「数式 ( FORmula) を変換する (TRANslate) 」言語でした。
これに対し、仕事 (COMmercial) でつかえる言語、COMTRAN (1957) を作ったのです。
COMTRAN は普及しませんでしたが、これをベースとして COBOL (1959) が作成され、広く使われるようになりました。
この当時、メモリは貴重でした。
そのため、日付などを入れる際に、1957 年を 57 というように表記するのも当たり前でした。
しかし、これは良いやり方ではない、とボブは気づきました。
このままでは、上の桁が変化する 2000 年には、多くのソフトが誤動作するに違いない。
この指摘を行ったのは、1971 年でした。
2000年問題の危険性の指摘でしたが、当時としては「30年も先に、今作っているプログラムが使われているわけがない」と誰も相手にしなかったようです。
実際には、古いシステムは「誰も完全な動作を把握できていない」ために更新されることなく、使われ続けました。
そして、彼の指摘通り、1990年代後半に社会的な問題となるのです。
彼はこのときにも、2000年問題の対処を再び考えています。
すでにソースコードが失われ、実行バイナリしかないソフトに対してパッチを当て、「50以下は +100 してから比較することで、年の順序を間違えないようにする」というような解決方法でした。
…実際に、これで延命された古いシステムが多数あります。
2050 年に問題が起きるかもしれません。
＃さすがにそれまでにはシステムが更新されている…と思いたいが、彼が指摘した 30年後に、実際に 2000年問題は起きたのだ。
2050年も、あと 33年しかない。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、西和彦さんの誕生日(1956)
日本のパソコン黎明期を支えた人です。
日本のみならず、世界的な影響も与えているのだけど。
とにかく、行動力があります。動かなくてはならないタイミングを逃さない。
日本で TK-80 が発売されたとき、数年前にアメリカでおきた「Altair 8800」と同じ現象が起きる、と直感します。
知人らと共にアスキー出版を設立し、パソコン情報誌の「アスキー」を創刊。
そして、次に必要なのは BASIC だと考えます。
すぐにアメリカにとび、Altair BASIC を作っていたビルゲイツをつかまえ、自分をマイクロソフトの極東代理店に認めさせてしまう。
…ゲイツの証言によれば、英語が下手で会話にならない日本人がやってきて、「とにかく俺を日本担当にしろ」の一点張りなので、とりあえず帰ってもらうために承諾したのだとか。強引です。
西は、「アスキーマイクロソフト」を設立。社長になります。
さらにその後、マイクロソフトの副社長も兼任します。
でも、これでマイクロソフトは「アメリカの小さな企業」から、世界企業へはばたく足がかりを得ます。
西が、日本で次々と BASIC 開発の仕事を取り付けてきたのです。
日本電気（のちの NEC）の PC-8001/8801、新日本電気（のちの NEC ホームエレクトロニクス）の PC-6001、富士通の FM-8/7 、日立 BASIC MASTER 、沖 if800…
日本のパソコン黎明期に登場したライバル同士ですが、「マイクロソフトの BASICを搭載する」という共通点がありました。
＃他にもありますが、代表的なものだけ。
なお、SHARP の MZ / X1 は独自の BASIC を搭載していました。
PC-8001 などは、NEC の作成する機械に対して BASIC を供給する契約でした。
しかし、if800 などでは設計方針などの重要な会議にも参加していますし、後のハンドヘルドマシン、NEC PC-8201 / Tandy TRS-80 Model 100 などは、設計からすべてを行い、京セラが製造し、販売会社を見つけて売り込んだものです。
＃NEC と Tandy のマシンは、ほぼ同じハードウェアで、BASIC などには違いがある。
これだけでも、当時の西の影響力の大きさがわかります。
マイクロソフトを本当に大企業に押し上げたのは、IBM への BASIC と OS の供給でした。
当時のマイクロソフトは、ほぼ「言語専門」の会社。
IBM からの依頼は、BASIC でした。しかし、FORTRAN と COBOL と Pascal も必要としている、と知り、それら全部を供給する契約を結んだのです。
まだ小さなマイクロソフトにとって、これだけでも期日に間に合うか不安な契約。
でも、さらに IBM が OS の供給先を探していると知った時、西がその契約もマイクロソフトで取ろう、と言い出します。
ビル・ゲイツは猛反対したようですが、最終的に西の熱意に負け、IBM に「OS も供給できる」と連絡を入れます。
現在マイクロソフトは巨大企業ですが、このときに西が副社長をやっていなければ、そうはならなかったわけです。
西は日本のパソコン業界に顔が広く、多くのパソコンの構想に関与しました。
先に書いたように、PC-8201 / Tandy TRS-80 Model 100 などは、マイクロソフトとアスキーが設計し、京セラが製造し、各社のブランドで販売されました。
このようなＯＥＭ（相手ブランドでの製品供給）の先に、基本設計を共有しながら各社が特色のある互換機を作る、という構想が生まれます。
MSX パソコンの登場です。もちろん、BASIC はマイクロソフト製でした。
もっとも、マイクロソフトは名前を貸しただけで、ほとんどアスキーで作成したそうですが。
＃マイクロソフトは、このころすでに 16bit 向け BASIC に軸足を移しつつあり、今更 8bit をやるつもりはなかった。
ただ、MSX の成功を「傍観」したことで、標準化ビジネスの旨味に気付き、以降 OS の機能拡充により「機種差を吸収し、標準化する」戦略を取り始める。
その後、マイクロソフトの株式公開を機に、西はマイクロソフト副社長を解任されます。
西はマイクロソフトが半導体事業も手掛けるべきだと考えていて、一方ゲイツはインテルと盟友関係にあるので、インテルの市場には手を付けるべきではないと考えていました。
アスキーもマイクロソフトもともに大企業となり、「企業として競合関係にある」ことも兼任を難しくしていたようです。
アスキーマイクロソフトも、マイクロソフトの日本代理店ではなくなりました。
大きな仕事を失ったことで、この後親会社のアスキーにも影響を与えます。
この後はパソコンの歴史というよりは「アスキーの顛末」になってしまうので、話はここらへんで終わりにしましょう。
西さんの人生については、ご自身のページで書かれている年表が詳しいですし、失敗談なども赤裸々に書かれていて面白いです。
また、西さんのページには作成に関わったパソコンなどの一覧もあります。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |