Advice from Doug Mcilroy
Doug Mcilroy からのアドバイス。

Attached by magnet to the wall of my office is a yellowed sheet of paper, evidently the tenth page of an internal Bell Labs memo by Doug McIlroy. Unfortunately, I don't have the rest of the note.
私のオフィスの壁に磁石で付けられているのは黄色くなった紙のシートで、明らかに Doug McIlroy による１０ページに渡るベル研内部のメモです。 残念なことに、他のノートを私は持っていません。

When this was written, in 1964, Bell Labs computing was for the most part done on IBM 7090 or 7094 equipment, mostly in batch mode, using an IBM 1401 to prepare tapes from card decks and print output, also transmitted by tape between the mainframe and the 1401. This kind of operation was typical of the age. Bell Labs was somewhat apart from the ordinary; the operating system was locally developed (BESYS), and there was a certain amount of advanced hardware attached. Some of this was in direct support of smooth batch operation, like gadgetry on the tape drives to crossbar the drives with their channels, and some was with display devices, like the PDP-7 computer used to control a Graphics II display system -- this was the machine commandeered a bit later to build Unix on.
1964 年にこれが書かれた時点では、 ベル研のコンピュータの大半は IBM の 7090 か 7094 装置で、 ほとんどバッチモードで稼働しており、 カードデッキからテープを用意したり 印刷するためには IBM 1401 を使ってました。 この手のオペレーションは時代を象徴するものでしたが、 ベル研では一般とは少々違っていました; オペレーティングシステムは所内で開発されたもの (BESYS) であり、 いくつかの高度なハードウェアが接続されていました。 このうちの幾つかは テープドライブをチャネルに切替えるための玩具だとか、 Graphics II ディスプレイシステムを制御するための PDP-7 コンピュータなど、 円滑なバッチオペレーションをサポートするためのものでした。 この PDP-7 が、のちに Unix を開発するために奪い取られたマシンです。

In the software area, besides BESYS itself, there was considerable language work, notably BLODI (essentially, early dataflow architecture) and Snobol (string processing). McIlroy's particular specialty at that stage was macro-processing, but he had and has broad interests.
ソフトウェアの領域では、 BESYS それ自身に加えて、 注目すべき言語に関する仕事がありました。特に BLODI (基本的に初期のデータフローアーキテクチュア) と Snobol (文字列処理) はその顕著な例です。 その時点での McIlroy の専門分野はマクロ処理でしたが、 幅広い分野に関心を持っていました。それは今でもかわりません。

1964 was also the time that the Multics project was at the point of beginning. Some of these thoughts either influenced the design of Multics or encouraged Bell Labs to take part in it. One in particular was important to us.
1964 年は Multics project が始まったばかりの時期でもありました。 この考えの幾つかは Multics の設計に影響を与えたり、 それに参加するためベル研を後押ししました。 とりわけ、そのうちの一つは私たちにとって重要でした。

Here is the page-on-the-wall, retyped. A PDF scan (pretty big at 49K) scan of the original lets you see that it was produced on a typewriter (and also the damage over the years, and that the duplicated "when" phrase is historically accurate).
ここに打ち直された壁の紙があります。 PDF scan はタイプライタで打ち込まれたオリジナルを 皆さんにお目にかけるためスキャンしたものです。 (長年に渡る損傷もありますが、複製された日付は歴史的に正確です)

- 10 -

Summary--what's most important.
要約 -- 何が一番重要か

To put my strongest concerns into a nutshell:
私の強い関心事を手っ取り早く押し込むために

1. We should have some ways of connecting programs like garden hose -- screw in another segment when it becomes when it becomes necessary to massage data in another way. This is the way of IO also.
1. 庭の水巻用ホースのようにプログラムを接続する方法が必要である -- もう一方へメッセージデータを送り込むことが必要になった時に もう一つのセグメントにねじ込むような。 これは入出力の方法でもある。

2. Our loader should be able to do link-loading and controlled establishment.
ローダーはリンキングローディングと制御の確立ができなければならない。

3. Our library filing scheme should allow for rather general indexing, responsibility, generations, data path switching.
我々が工夫したライブラリは一般的なレベル以上の索引能力、 応答性能、生成能力、データパスの切替を可能にしなければならない。

4. It should be possible to get private system components (all routines are system components) for buggering around with.
プライベートなシステムコンポーネントを可能にしなければならない。 (全てのルーチンはシステムコンポーネントである。)

M. D. McIlroy
October 11, 1964

What did Doug mean, and what came from the thoughts?
Doug は何を意図したのでしょうか？ また、この考えから何が生まれたのでしょうか？

• Point 1 is the interesting one. It provides the historical background for Doug's encouragement of the Unix pipe notation. The linked paper gives appropriate credit; in interviews, Doug has been explicit in saying that he very nearly exercised managerial control to get pipes installed.
  第１項は興味深いものです。 これは Unix の pipe 表記 に関する Doug の激励の歴史的背景をを提供します。 リンクされたペーパーは適切な名誉を与えます; インタービューで、 Doug は pipe の導入のために、もう少しのところで 管理者としての権利を行使するところだったことを 明確に述べています。
• Point 2 is a bit mysterious without further context. It is possible to read it as advocating mechanisms (dynamic linking) that were pioneered in Multics.
  第２項はもう少し説明がなければ少々不可解です。 Multics がパイオニアとなった (ダイナミックリンクのような) メカニズムの主張と理解することができます。
• Point 3 is almost certainly the one that still bugs Doug. All sorts of mechanisms and utilities are around and used (source code control, registries, WWW search engines, and on and on), but the problem of indexing and finding relevant information is tougher today than ever before, even on one's own hard disk, let alone the WWW.
  第３項は(現在でも)まだほぼ確実に Doug を悩ますものです。 全ての種類のメカニズムとユーティリィティはありますし、 また使用されてもいます。 (ソースコードの管理、レジストリ、WWW の検索エンジン、などなど) しかしインデックス付けの問題と適切な情報の探索は これまでより (WWW はおろか、自分のハードディスク上でさえも) さらに難しいものです。
• One might argue that Point 4 is to some extent under control, depending on what Doug was really getting at. One thinks about the dynamic linking mechanism combined with search paths in Multics (close to the time of the note) and its offspring in more recent systems. Possibly one could create a connection to the free software movement, but this would be tenuous at best; I suspect that he was thinking "how can I test this seemingly monolithic program against the sin routine I've just written and want to test?".
  一つは、 ポイント4がある程度までコントロールされると主張するかもしれないし、 ダグが実際に手に入れていたものに依存します。 一人は、Multics(ノートの時間に接近した)の中の探索パス およびより最近のシステムでのその結果と結合した 動的リンキングメカニズムに関して考えます。 恐らく、一つは、フリー・ソフト移動への接続を作成することができました。 しかし、これ?ﾍせいぜい非常に細いでしょう; 私は、 「私が、どのようにたった今書いた 罪ルーチンに対するこの外見は単一体のプログラムをテストすることができますか。 また、テストしたいことができるか。」と、 彼が思っていたのではないかと疑問に思います。

Point 1's garden hose connection analogy, though, is the one that ultimately whacked us on the head to best effect.
しかしながら、 ポイント1庭ホース接続類似は効力を破るために 頭の上で結局私たちを強打したものです。