ラベル research の投稿を表示しています。 すべての投稿を表示
ラベル research の投稿を表示しています。 すべての投稿を表示

2016年2月18日

大学で過ごした日々

1984年から東大で学部から修士まで6年間、2002年から阪大にて外部の研究協力者として、また社会人博士の学生として3年過ごし、2010年から京大では教授として3年弱勤務した。残念ながらそれらで得た結論は皆同じで、どこも組織としてはダメだった。もちろんその過程でいろいろな出会いはあったし、勉強もできたことを考えれば、全部無駄だったとは思っていないけれど。

最初に大学に行ったときは、コンピュータ屋は目指していなかった。大学の中では計算機屋の地位は低い。そして率直に言って日本の大学は計算機科学のレベルは高いとはいえない。東工大のTSUBAMEのような例外的成功例はあるが、基本的に米国の後追いを越えていないし、また越えられない理由が無数にある。もしコンピュータ屋を目指すのであったなら、学部の時点でUC BerkeleyやStanfordやMITを目指すべきだったと思っている。もっとも、お金もなかったし体力もなく健康でもなかったので叶わぬ夢だったが。

もっとも、そうはいっても、結局、自分は理論物理屋も地球物理屋もできず、さりとて成績も良くなかったのでそもそも理学部情報科学科への進学はかなわず、工学部応用物理関連学科群に進学することになった。本格的にコンピュータ屋に復帰したのは、修士の時に情報工学専攻で学ぶことになってからである。これが良かったのかどうかは、自分では判断できない。まあ、好きなことではなく、目をつぶってでもできることでなければ人間はロクに稼げないので、そういう意味では向いていたのかもしれない。

21世紀になっても相変らず旧7帝大が権勢を振るっているのが日本の実情だと個人的には思っている。国公立私立を問わず、文科省が生殺与奪を握っている以上、これは不可避かもしれない。国立大学も2006年に国立大学法人と名称を変えたとはいえ、どの大学も運営は官僚的そのものであり、計算機科学のような論文数も少なく何をやっているかわからない分野には理解は低い。

大学は基本的に外部との交流をものすごく嫌う。中の組織は皆それぞれの派閥を作りたがるので、常に相互監視疑心暗鬼の世界にある。このような状況はこの30年弱で変わるかと思ったが、大して変わっていない。かつて京都大学にて全学の情報セキュリティに関する仕事をしていたときには、多くの教員から敵意に満ちた批判を受けた。まあ職務上無理からぬこととはいえ、組織としての統制がまったく効いていない状態では、徒労感のみ残る仕事だったことは否めない。実際には、統制される側が自律しているとはお世辞にもいえない状況であり、日々起こる事案に対応しなければならず、現場は混乱の極みだった。

京都大学でもう一つ感じたのは、学生が自由を求めていろいろ騒ぐのはいいとして、本来それを受け止める側の教員までが同じように騒いでいる例が少なくないことだった。京都大学は対話を重視する大学をスローガンとしてかかげているが、実際には各人自分勝手な主張をしているだけで、何の対話にも教育にもなっていないように見えた。もちろん粛々と日常業務をこなし、一切動じていない先生方もたくさんおられたのもまた事実だが。自分もそのような日常業務をこなし、一切動じない教員になろうと努力はしたが、あまりにも不条理が多く、プロパーでないことによる立場の低さはいかんともしがたい状況であったため、結局健康を害してしまった。

そんなわけで、自分は大学に関しては、人生選択を誤ったなというのが率直なところである。計算機科学に限定するならば、北米のトップの大学へ行った方が遥かに実践的な勉強ができただろうし、現在なら他の選択肢はないに等しいだろう。

ただ、学術研究そのものに対する締め付けとコスト高騰の波は日本以上に北米は厳しい。コンピュータ屋の場合、大学を出てさらにテックベンチャーで滅私奉公して働くことを覚悟しない限り、自己破産でも免除されない学資ローンの借金で首が回らなくなることは想像に難くない。それが本当に正しい人生の選択なのか。そしてサンフランシスコの超高コスト社会で大きな出費を強いられるのが良いことなのか。


何が正しいか、今の私にはわからない。それが率直な感想である。

(初出: Facebookの個人アカウントでのNotes 2015年9月26日)

2014年4月1日

父 力武 常次 最終講義資料の公開について

父 力武 常次が東京工業大学理学部応用物理学科教授として行った最終講義の資料を,本日 CC-BY-NC-SA 4.0 ライセンスにて公開しました.

本資料の公開にあたり,ご助言いただいた東京工業大学名誉教授の本蔵 義守先生に深く感謝致します.

2013年8月2日

電子情報通信学会の技術研究報告に関する電子的利用の方針についての要望

本日,以下の文書を,電子情報通信学会 サービス事業部 会員課に対し送付し,同会著作権管理委員会に取り付いでもらうよう要望しました.諸々の問題があることは承知していますが,オープンアクセスが学術学会でも当たり前になっている現状を鑑みる限り,何らかの方針を早急に決める必要があると思っています.


電子情報通信学会 著作権管理委員会の皆様

貴会における技術研究報告に関する電子的利用の方針について,以下の通り要望します.

  • 貴会の著作権規程の基本方針についての以下URLから引用できる文書では,電子的利用の方針について,「技術研究報告につきましては引き続き検討中」とあります.この文書は平成20年4月の理事会にて決定された内容が記されており,すでに5年以上の時間が経過しておりますが,以下の事項について,ご回答いただきたくお願い申し上げます.

    • その後の検討結果はどのようになったのか
    • 仮に検討結果が確定していない場合,いつまでに検討が終了し,結論が出る予定か
    • 5年以上経過しても検討結果が出ていないことについての経緯の説明
    • 参考URL: http://www.ieice.org/jpn/about/kitei/chosakukenkitei.html
  • 以下の参考URLに述べられている利用申請基準では,「技術研究報告については、論文全文の電子媒体での利用については検討中であり、利用は不可である」とあります.電子的な公開があらゆる学術学会の研究報告で一般的になりつつある現状を考えた場合,この文言はすでに時代錯誤であると言わざるを得ません.
    つきましては,一刻も早く,技術研究報告の電子媒体での利用についての規程を整備し,少なくとも著作者自身が自分の技術研究報告全文を論文誌の論文同様に公開できるように(利用申請基準の例外事例1に相当する条件で)体制を整えていただきたく要望します.

現状のままでは,電子情報通信学会の技術研究報告を書く意味が事実上否定されているに等しいということを,著作権管理委員会の皆様にはご理解いただく必要があるのではないでしょうか.

以上,Web上でもメールでも結構ですので,ご回答いただきたくお願い申し上げます.

平成25年(2013年)8月2日

力武 健次
電子情報通信学会 シニア会員

2013年8月6日追記: 本件について,電子情報通信学会 会員サービス部より,「要望受け承りました。関連委員会で検討して、ご回答いたします。少しお時間を必要としますので、ご了承ください。」という旨のメールの返信を得ました.

2014年4月6日追記: 本件に関し,電子情報通信学会の「本会出版物に掲載された論文等の著作物の利用申請基準」が2013年10月24日に改訂され,技術研究報告についても論文誌同様の判定基準によって,「非営利目的による利用かつ同学会の利益を不当に侵害しない範囲における利用」であれば,利用申請不要となったことを確認しました(関連規定のページ,「利用申請基準」のPDFを参照).関係者の方々のご努力に感謝すると共に,引き続き完全オープンアクセス化への努力を継続していただきたいと考えます.

2013年1月31日

京都大学を退職するにあたって

(写真: http://www.flickr.com/photos/romanketchup/2867937983/, licensed CC-BY, edited by Kenji Rikitake)

2013年1月31日付けで,京都大学を退職する.体力の限界に達してしまったからである.

退職することを決めてからそれほど時間の経っていない今, 多くをあまり語る気にはならない. 守秘義務のある身でもあり,そもそも多くを語ることはできない. とはいえ,最小限の事実は,書いておこう.

2012年11月からの3ヶ月間,休業していた.正確にいえば,病気休暇を取って療養していた. 病名は「うつ状態」.いろいろなことが重なって,10月末には知的にも,体力的にも,速度も集中力も 著しく鈍くなってしまっていた.そこでかかりつけの医師に相談したら,すぐに休養すべきと判断されて, この病名の診断となった.

24時間1年中戦わなければならない日本の社会では,病気で休暇は取りにくい. なにしろ皆勤が是とされ,苦痛にあえぎながらラッシュアワーの電車に乗って出勤し, 這ってでもカイシャに行くのが賞賛される社会である. まして管理責任を持つ立場であれば,その責任が取れなくなる状況となることは許されない. 言い方を変えれば,管理責任のある立場の者が病気で長期間の休暇を取るということは, 実質的に退職するということを意味する. それでも病気休暇を取ったのは, この状態で仕事を続けたら二度と再起できなくなるだろうという予感があったからだ.

本来,大学の教員という職業であれば,もう少し時間的にも体力的にも余裕を持てても良かったはずである. しかし,

  • 職場でも出張先でも研究ではなく業務対応が最優先であったこと,
  • そしてその業務が一刻を争うものであったこと,
  • さらに業務関連の会議だけのために長距離出勤を繰り返し余儀なくされたこと,
これらが重なって,くたびれ果ててしまった,というのが正直なところである.

どれくらい疲れていたのかは,自分ではよくわかっていない. ただ,2012年11月上旬に病気休暇に入ってから,普段ならまずない深刻なカゼを引いてしまったことを考えると,かなり重症だったように思う. そして,2012年の4月以降のこと,特に10月に入ってからどんなことが起きていたかについて,記憶があいまいになってしまっている. 思い出そうとすると,モヤがかかったようになり,その先に進めなくなるのだ. だから今はあえて思い出さないようにしている.

病気休暇中の3ヶ月は,日常生活を着実にこなすことに努めた.多くはあえて書かない. しかし,この2年半あまりの間にできていなかったことを,かなり取り戻せたとは思う. 歩く量が減ってしまったため,脚力が下がったのは,改善しなければならないとは思うが.

今回の退職にあたり,ひとつ反省すべき点があるとすれば,1990年4月〜1992年4月までの 日本DEC在職時にイヤというほど痛感した長距離通勤,いや通勤そのものの怖さを甘く見ていたことだろう. 通勤は身体を蝕む.それもかなり深刻に蝕む.残念ながら私はこの生活に耐えられなかった.

今後の自分の人生について, 1ついえることは,Erlang/OTP,そして分散システムにかかわり続けていくことは確実だと思う. ただ,情報セキュリティはもはや「研究」の対象たり得ないところまで世の中は変わってしまった. 情報セキュリティは本来の「安全保障」であるセキュリティの専門家がやるべき仕事になった以上, 私のような強靭な身体を持たない者は手を引くべきだろうと考えている. そして,今回の退職で職業研究者としての自分のキャリアは一度終わったと思っている. とても残念だがこのことは認めなければならない. もちろん,日々の生活の中で,研究者的態度と探究心は維持していくだろうし, それがなければ技術者,いや人間としての自分を維持できないことは自明ではあるのだが.

最後に,かつてお世話になった研究者のTweetを紹介する.至言である.

「ちなみに大学は個人のパフォーマンスがすべてなので、体調を崩さずにトップパフォーマンスを維持できる人にしか向いてない。 ときどき、大学教員に転職して愚痴ってる元会社員がいるけど、考えが甘いと言うしかない。」 (https://twitter.com/youki10/status/271274995303448579)

2011年4月4日

Erlang Workshop 2011 のご案内

関数型言語の国際会議 ICFP の今年の開催地は東京です.ICFP のアジアでの開催は初めてですね.HaskellもGHCがGitHubに移ったり,OCaml,Scala,F#と,関数型言語も随分増えてきました.そんな訳で関数型言語界隈はこのごろ活気付いて います.

2011年は日本における関数型言語ブレイクの年になるか? なると嬉しいなあ…という方にお知らせです.

ICFP 2011 に併設して Erlang Workshop 2011 が開かれます.Erlang Workshop にはどなたでも参加できます.発表内容の議事録を見ると,コンパイルや形式変換などのプログラミング言語理論だけでなく,テストやライブラリの話など,Erlang/OTP 関連技術の実践応用に至る幅広い論文発表がなされています.

「Erlang,良さそうなんだけど,本当に関数型言語として使えるの?」「Erlang/OTPの上に乗っているCouchDBやRabbitMQは使っているけど,他にどんな使い方があるんだろう?」…そんな疑問を持っている方は是非 Erlang Workshop に参加してください.世界中のErlang経験者が一堂に会して,Erlang/OTPの奥深い技術について聞けるのは,Erlang Workshopだけです.

さて,Erlang Workshopは聞くだけではなく,発表をする場でもあります.特に今年は日本での開催ですので,是非是非日本の皆さんのErlang/OTPによる取り組みをご紹介していただければ,主催者達も大変喜ぶかと思います.

発表の形式は以下の3つです.

  • 技術論文: 言語拡張,現状の改善,言語構成要素の形式意味論,プログラム解析と変換,仮想マシンの拡張とコンパイルのテクニック,他言語でのErlangの実装や他言語とのインターフェース,その他新しいツールについて.最大12ページ.
  • 実践応用論文: 実世界でのErlangの応用.特定作業のためのライブラリ,特定分野における応用からもたらされた経験,問題解決でのErlangのエレガントな応用.最大6ページ.(ここへの投稿は次のポスター発表に割り当てる可能性がありま す.)
  • ポスター発表: 本ワークショップの目的に合致した話題に関する説明.最大2ページの発表の概要(abstract)と要旨.発表は1時間のデモ枠で複数個同時に行われます.
の3つとなっています.

論文投稿の方法の詳細については Call For Papers (http://www.erlang.org/workshop/2011/) を参照してください.

締切等についてですが

  • 論文投稿締切: 2011年6月3日
  • 論文査読結果通知: 2011年6月17日
  • 最終原稿締切: 2011年7月13日
  • ワークショップ: 2011年9月23日
という流れになっています.

実は,私はこのワークショップの実行委員長です.会場でお会いできるのを楽しみにしております.Erlang Workshop 2011へのご支援,ぜひよろしくお願いします.

(CUFP 2011 Tokyoに関する紹介ページ にインスパイアされて(笑)書いてみました.)

2011年2月8日

はやぶさのカプセル

JAXAの小惑星探査機「はやぶさ」が地球に落としたカプセルの一部を見る機会に恵まれた.さすがに展示会場は大変混雑しており,1~2分しか見ることはできなかったが,それでも本当に宇宙から戻ってきたカプセルを見るのはそれだけで感慨深いものがあった.最も印象的だったのは背面ヒートシールドであった.また,パラシュートが往復の長い行程に耐え,機能した状態で戻ってきたのも驚きだった.

「はやぶさ」を動かしていたソフトウェアはどのようなものだったのか.そしてそれを支えた技術はどのように機能したのか.きっと広義のフォールトトレランスを実現していたのだろう.過酷な条件に耐えるためのソフトウェアには,停止は許されないからだ.異常発生時には確実に全体を再起動させるコードも組み込まれていたに違いない.

打たれ強いソフトウェア・システムを作るにはどうすればよいのか.そんなことを背面ヒートシールドを見ながら考えている.

2011年2月4日

Erlang/OTPの抱える基本的な課題

Erlang(日本語では「アーラン」よりも「えあらんぐ」の方が発音により忠実らしい)/OTPのブログを一応標榜している(苦笑)ので、今後のErlang/OTPの課題などまとめてみる。

まず技術的には
  • 暗号に関わる技術(ハッシュ関数、共通鍵暗号、公開鍵暗号、疑似乱数)を、どう並行実行可能にしていくつもりなのか
  • 数日、数週間、数ヶ月単位の大規模遅延に耐えるネットワーク技術 (delay tolerance)
  • IPv6の基本的サポート、特にDistributed Erlang / epmd、そしてそのSSL化サポートの確認
  • DNSSEC対応のリゾルバ for inet_res module
  • BEAMの実装に起因するバイナリヒープの扱い、ならびにそれを意識して高速にNIFを書くための技法(実測が必要)
  • 状態保持量の少ない疑似乱数: Wichmann 1982 / Wichmann 2006 / LShift / XOR32
  • 状態保持量の多い疑似乱数: SFMT ((2^19937-1) or (2^607-1))
  • NIFによるTAI(国際原子時)の扱い
  • BEAM間の権限分離手法(FreeBSD Jail? それとも一般的な仮想化?)
  • そもそもPort, Linked-In Driver, NIFの使い分けをどうする?
なんて話があるわけです。

いろいろといじってみたいプロジェクトもいっぱいあるのですが、一部だけ。

そして当然今年は
という大イベントが控えております。

課題が山積しまくりで大変であります。

2009年8月22日

ErlangとDNS

(初出:2009年8月22日 はてなダイヤリーより)

DNSはインターネットの各種基本プロトコルの中で最も扱いにくいもののひとつ.本当に高速な処理(=100kqueries/sec or faster)が要求される局面では,たぶんErlangのように一度VMが間に入る言語システムでは間に合わない.しかし,Erlangは並行処理が 書き易いという利点は,DNSの各種サブシステムでは役立つと思う.ちょっとしたキャッシュサーバ,コンテンツサーバなどには向いているだろうし.もしErlangで何かDNS関連のアプリケーションを作るなら,yawsやMochiwebみたいなものを目指すべきだろうと思う.

DNSの研究開発というのは実は非常に難しくて,

  • ステークホルダーが多く,彼等の大多数は変化を望まない(特にISP)
  • ドメイン名自身が商標ビジネスの一部になっているため,技術論だけでは動かない
  • 明文化されていない約束事が多く,それらを知らないと簡単に開発できない
  • 何かやろうとすると影響範囲が大きく,通信量やセキュリティ脆弱性(フィッシングなどを含む)などの問題にすぐにぶつかってしまう
  • 過去のアプリケーション実装を無視した実験は実運用では事実上できない
などの問題がある.

そして,日本でDNSの研究開発を本気でやるなら,

  • JPRSでそういう仕事をする
  • WIDEのm.root-servers.netの仕事をする
  • ISPやレジストラで運用にかかわる
という,実はコーディングよりも,運用のスタミナが要求される非常に厳しい道以外にないんだろうと思う.残念ながら,私は上記のどれにも関われない状態のまま,挫折したけど.

個人であれば,神明達哉さんのように渡米してISCでBINDの開発にかかわる,という直球勝負をする方法もある.しかしこれはこれで生活を賭けなければいけないことで,そう簡単に誰でもできるわけではない.

ただ,DNSは研究開発だけじゃなくて運用や解釈も難しいので,DNS自身に関する知識や技はインターネットで何かやろうとする限 りはついてまわるし,覚えておいて損はないと思う.Erlang R13B01なら,まず lib/kernel/src/inet_dns.erl を読むことから始 めるべきだろう.

そして,DNS自身は,実装は今とは大きく変わる可能性があるけど,世界からドメイン名が消えてなくなる時が来るまでは残るシステムだろうと思う.

以上,つらつらとTwitterに書いたことをこちらにも.

2003年9月13日

Javaが生まれる前の話


1988年12月14日に行われた東京大学大型電算機センター会議室でのBill Joyの講演のメモ
Edited 13-SEP-2003 by Kenji Rikitake 力武 健次
(1988年12月14日に紙に書いた私的メモを編集したもの)

From V7 to Phase-3 (メモ原文ではΦ-3)
   The evolution of UNIX
   7 from AT&T (Sys V rel 3)
   7 from BSD (4.3)
Phase-3: restructured UNIX
   20年前とは基本的構造は変わっていない
MULTICSから3つのideaしか使っていない
  Processes : "GENIE" / Ken Thompson
  File System : KT (Ken Thompsonのことと思われる)
  Pipes: McIlroy
Shell以上がけっこう複雑になっている

その後の改造
   VAX-11/780
      virtual memory
      keep PDP-11 model
      paging is invisible
        → 3BSD 1979
   Local Area Networks
      Ethernet
      TCP/IP
      model of sockets
        → 4BSD 1981
Problems
   No "tenex" pmap functionality → mmap() ← 載らず
   Communications is asynchronous → select() ← まだ不十分

New technologies -> New system facilities -> Larger O/S

Trends

   1. Minis -> WSes & Servers ⇒ NFS
   2. Library Complexity      ⇒ Dynamic Linkage
      -> back to MULTICS

Graphics and Windowing -> complicated
   5 kinds of graphics
      X11 PHIGS PostScript Renderman & what? (image processing)

Current UNIX:
   Applications: Communication が不足
   Unix Kernel:  networking 1M lines
                 original 200K lines
   Graphics: 1M lines

4 Application Styles
   main(): App.
   sleep(): Traditional Kernel
   Networking
   Graphics
   ⇒ The single paradigm:
         No Concurrency/Parallel Programming
         Too Complex

New Central Concepts
   Mach -> ports & RPC -> first bigger -> next smaller
     --> HUGE DEFICITS ("first cut taxes" ではだめ)
   ⇒ UK(英国)みたいに <first cut spending>

Sun's Approach:
   Focus on applications: one programming environment
     Concurrency / C++ / Shared memory / Fiber optics
   ⇒ Making UNIX be an application

Status of the nre project:
   Nucleus (wnj: assembler (Microcode)) ... 1 sys call
   Language (mitchell, powell... ) ... C++++-=
   Services (gingell, ...) ... UNIX, networks...

Key will be success of language

C++ ++ -= ⇒ implemented in ANSI C ⇒ SPARC (microcode)
    ++:      concurrency / parameterized types / garbage collection
       -=:   general complexity (unsafe function ⇒ ANSI C で書け)

Summary:
   Phase 3 is RISC for OS
   RISC relative to Applications
   Not a OS kernel; applications platform!
   This is first public talk -> do work, not promote.

-----

Cross examination or Q&A session

UNIXとのコンパチビリティはどうか?
→上位OSで確保する

C++とObjective-Cは?
→どっちも生産性向上のためのツールである
  C++を使っている

フォールト・トレラント性はどうするつもりか?
→オブジェクト指向ならば各オブジェクトのコピーは楽である.
  これを利用してシャドウ・ディスクを作れる.

多言語での可能性は?
→ほとんどの言語はinterpreterである.
  良いinterpreterはむつかしい.

SPARCの命令は今後拡張されるか?
→固定している.整数乗算や64bit長についてでさえ議論が行われているが,
  これからどうなるかはもっと若い人にまかせたい.
  5000ゲート+レジスタ・ファイルでしかないから,改造は楽である.
  いずれにせよ,386みたいにやればインテルに告訴されるだろうが,
  SPARCではそんなことはせず広めていきたい.
  ハードウェア記述言語が米国の大学では開発されており,
  それをつかってSPARCを作れる.それにはスーパーコンピュータが
  必要であろう.(逐次探索でやるしかない)

SPARCのコンテキストスイッチングはおそい.
→全部レジスタを変える必要があるかどうかは,統計的な問題である.
  言語の複雑さにもよるであろう.

OSと言語との関係は?
→UNIXではCのmain()の世界で生きる.しかしこれだけではgraphicsなどには
  対応できる環境がない. C++++-= ではこれらに対応できる環境を提供する.
  さらに一つでやりたい.

グラフィクス以外の音声などのメディアは?
→リアルタイムOSに近くしたいと思う.
  (レスポンスの時間が予測できるようにしたい)
  そのためには非常に速いマシンが必要である.
  小手先の対応では対処できない.

DVIは見たか?
→あまり好きではない. orphan technology だと思う.
  絵が汚い.ISDN用に絵画を圧縮したいんだと思うが,Appleの方が良く
  やっていると思う.みんなやっているから,すぐにできるだろう.
  机の中にTVが入るだろう(HDTV)

Securityはどう実現するつもりか?
→ simple .vs. diverse
   common .vs. complex
   単純なものは弱い.
   common ⇒暗号を使う必要がある.
   モジュール化して,違う組み合わせで違うシステムでやる必要がある.
   Cは堅いが,もろい←強固に書く必要がある.
   建物と違い,動かす前にテストできない.

暗号はどうするつもりか?
→ DESはどうしようもない.政治の問題だ.
   公開鍵暗号は研究されているが,これを広めようとすれば政治問題になる.
   その証拠にまだ第3世界はエニグマ暗号を使っている.
   トロイの木馬みたいだけど,銀行のシステムを攻撃してやれば
   みんなわかるんじゃないだろうか.

Phase-3 では「きれいな」プログラミングを強要されるだろう.
ガベコレなんかがあると, malloc()なんかは使いにくくなる.
→ 古いプログラマの10%が理解してくれればいいと思う.

プログラムは C++++-= ではエレガントになるのか?
→ 今マニュアルがないので例を示すことはできない.
   できるだけ変えずにエレガントにするのは,むつかしいだろう.
   コンパイラが答えられないような例があるのは情けない限りである.

SunのHardware仕様書がない.
→ 手には入れられるようにしてある.
   Sunのソースコードも提供している.
   いくつかのドライバはしょうもないだろうが.

680x0 が× SPARC が○となったのはなぜか
→ 自分でデザインするしかなかった.
   半導体業界は協調してくれないので大変だった.
   SPARCは hybrid chip の核として使われることを予想している.
   わずか20000ゲートでしかない(2μmテクノロジ)
   そのうち家具同士で通信することもできるようになるだろう.
   Nano Technology
      Drexler "Engines of Creation"

大容量記憶装置はどうなるか?
→ Audioを見よ.CDプレーヤーは安い容量はでかい.
   いわゆるdiskはRAMになり,CDが主流になる.
   そのうち原子構造を利用したものになる.

[以下雑談となり終了]

編者注:

  • C++++--= (Cプラスプラスプラスプラスマイナスマイナスイコール) はその後 Java となり実用化された言語の祖先であったと考えて良いだろう.
  • 1988年末当時,まだSun-4が登場したばかりであり,UNIXあるいはSunOSもソースコードを見るにはAT&Tのライセンスが必要だった.また,当時は米国国務省の認めない暗号技術の輸出は厳に禁じられていた.


[end of memorandum]